Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #127173 > unrolled thread

Compiling and linking code from different places in the file system

Back to article view | Back to comp.lang.c

Contents

  Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-01 14:40 +0000
    Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-01 14:55 +0000
      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-02 21:05 +0000
        Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 01:18 +0000
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:03 +0000
        Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 22:37 -0800
        Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:23 +0000
    Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 11:11 -0500
      Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 13:51 -0500
        Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 11:02 -0800
      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 09:48 +0000
        Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 04:06 -0800
          Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 05:24 -0800
            Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 06:43 -0800
      Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-06 13:51 -0800
    Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-01 22:46 +0000
      Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 15:27 -0800
      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 12:25 +0000
        Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 04:53 -0800
        Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 15:32 +0000
          Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 08:02 -0800
          Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-04 07:52 +0000
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-04 08:43 +0000
            Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-05 07:58 +0000
              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:37 +0000
                Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 21:02 +0000
            Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-05 15:29 +0000
              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 04:54 +0000
                Re: Compiling and linking code from different places in the file system Robert Wessel <robertwessel2@yahoo.com> - 2018-03-07 00:33 -0600
                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 09:55 +0000
        Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-04 07:39 +0000
          Re: Compiling and linking code from different places in the file system Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-07 05:00 -0800
            Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-07 14:09 +0000
              Re: Compiling and linking code from different places in the file system Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-07 14:26 +0000
                Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-07 16:35 +0000
                  Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-07 09:32 -0800
                    Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-07 10:11 -0800
                      Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-07 11:12 -0800
                        Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-07 12:01 -0800
                          Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-07 15:43 -0800
                            Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-07 19:18 -0800
                              Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 09:59 -0800
                                Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 10:28 -0800
                                  Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 13:36 -0800
                                    Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-08 21:47 +0000
                                      Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 15:03 -0800
                                    Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-09 09:59 +0100
                                      Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 10:33 -0800
                                        Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 12:27 -0800
                                          Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 20:48 +0000
                                            Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 13:31 -0800
                                              Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-10 18:31 +0100
                                                Re: Compiling and linking code from different places in the file system Robert Wessel <robertwessel2@yahoo.com> - 2018-03-10 13:22 -0600
                                              Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-10 19:15 +0000
                                          Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 13:28 -0800
                                            Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 14:13 -0800
                                              Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 14:45 -0800
                                        Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-10 17:39 +0100
                                          Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-10 19:00 +0000
                                          Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 08:26 -0700
                                            Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-12 17:06 +0100
                                              Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 10:23 -0700
                                                Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 18:42 +0000
                                                  Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 12:20 -0700
                                                    Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 20:27 +0000
                                                      Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 14:12 -0700
                                                    Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-13 11:12 +0100
                                            Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-12 09:23 -0700
                                              Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 10:38 -0700
                                              Re: Compiling and linking code from different places in the file system David Kleinecke <dkleinecke@gmail.com> - 2018-03-12 11:41 -0700
                                                Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 12:10 -0700
                                      Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 12:09 -0800
                                        Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 20:46 +0000
                                        Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-10 18:35 +0100
                                          Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 08:54 -0700
                                            Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-13 08:39 +0100
                                  Re: Compiling and linking code from different places in the file system Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 11:03 -0700
                                Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-11 07:37 +0000
                                  Re: Compiling and linking code from different places in the file system David Kleinecke <dkleinecke@gmail.com> - 2018-03-11 14:22 -0700
                                    Re: Compiling and linking code from different places in the file system Spiros Bousbouras <spibou@gmail.com> - 2018-03-11 21:48 +0000
                                      Re: Compiling and linking code from different places in the file system David Kleinecke <dkleinecke@gmail.com> - 2018-03-11 17:50 -0700
                                    Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-11 15:54 -0700
                                  Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 09:38 -0700
                            Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 10:48 +0100
                              Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 09:58 -0800
                                Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 22:03 +0100
                                  Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 13:55 -0800
                                    Re: Compiling and linking code from different places in the file system Spiros Bousbouras <spibou@gmail.com> - 2018-03-08 22:38 +0000
                                      Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 15:03 -0800
                                        Re: Compiling and linking code from different places in the file system Spiros Bousbouras <spibou@gmail.com> - 2018-03-08 23:15 +0000
                                        Re: Compiling and linking code from different places in the file system Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 10:44 -0700
                                          Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 03:47 -0700
                                    Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-09 10:10 +0100
                                      Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 10:10 -0800
                                  Re: Compiling and linking code from different places in the file system jameskuyper@verizon.net - 2018-03-08 14:21 -0800
                                    Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 15:10 -0800
                                      Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-09 10:13 +0100
                                        Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 10:10 -0800
                        Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 10:28 +0100
                          Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 10:28 -0800
                            Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 22:17 +0100
                            Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 13:26 -0800
    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:39 +0100

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#127683

On 12/03/18 16:26, supercat@casperkitty.com wrote:
> On Saturday, March 10, 2018 at 10:39:48 AM UTC-6, David Brown wrote:
>> On 09/03/18 19:33, supercat@casperkitty.com wrote:
>>> True.  I would suggest that designers of implementations should recognize
>>> the value of configuration options to support code written for earlier
>>> implementations.  I am rather disappointed that C implementations have not
>>> done a better job of allowing modules which have different expectations
>>> with regard to integer size to be linked together if all interfaces between
>>> them use fixed-size types.
>>
>> That seems a /very/ obscure need.  The only platform I can think of 
>> where it was common to use different sizes of "int" was the early 68k 
>> processors, where people sometimes chose to use 16-bit for speed. 
>> Compilers for these devices sometimes had command-line options to choose 
>> 16-bit or 32-bit ints.
> 
> Using 16-bit "int" would have also allowed for compatibility with code
> written for other platforms like the 6809 where "int" was 16 bits.  If
> compatibility with existing code weren't a consideration, many of the
> more troublesome parts of C syntax could have been cleaned up long ago.
> The fact that they haven't suggests that compatibility is seen as
> important.

The code would have been source-code compatible anyway - as long as
people don't make silly, unnecessary and invalid assumptions about sizes
without checking them.  And the code would never have been object code
compatible.

> 
>>> That's true when writing entirely-new code.  When adapting existing code,
>>> things are less clear-cut, especially if parts of it cannot be modified.
>>
>> If you have existing code that cannot be modified, and it makes invalid 
>> assumptions that don't apply on your current target, then you can't use 
>> it.  It is that simple.
> 
> So it would be impossible for a compiler targeting x64 to successfully
> process code that expects "long" to be 32 bits?  Maybe someone should tell
> Microsoft that.
> 

If code has been written using silly and unnecessary assumptions about
sizes (like a lot of DOS and Windows C code), then you can keep it
working by keeping these assumptions valid in other compilers.  This is,
I think, the reason why MS decided that long should be 32-bit on 64-bit
Windows - it was to reduce the amount of bad code that would have to be
changed by incompetent programmers who never understood how to write
portable C.  (This was not helped by MS' inability to make a C99 compiler.)

Of course, this did not help for code that had other silly, unnecessary
and invalid assumptions that Windows programmers liked to make - such as
that pointers can fit in a "long".  It seems that MS felt that this was
less common than the mistake of assuming "long" was 32-bit, and so that
was the size they picked for "long".  This is despite MS having a long
history of typedef's and macros for particular sized types.

[toc] | [prev] | [next] | [standalone]

#127690

On Monday, March 12, 2018 at 11:07:04 AM UTC-5, David Brown wrote:
> The code would have been source-code compatible anyway - as long as
> people don't make silly, unnecessary and invalid assumptions about sizes
> without checking them.  And the code would never have been object code
> compatible.

A module that assumes "int" is 16 bits could be object-code compatible
with one that assumes "int" is 32 bits if inter-module references use
"short" when a 16-bit type is required and "long" when a 32-bit type is
required, avoiding "int" entirely.  Parts of the Standard library could
be a nuisance, but most issues could be resolved by having Standard
Library calls map to one of two sets of symbols [e.g. so a call to "strchr"
would call either __strchr16 or __strchr32].  The only place that inter-
module calls would be a problem would be when using type va_list, and even
that could be handled by including within va_ptr a flag indicating what
kind of code called va_start.

> > So it would be impossible for a compiler targeting x64 to successfully
> > process code that expects "long" to be 32 bits?  Maybe someone should tell
> > Microsoft that.
> 
> If code has been written using silly and unnecessary assumptions about
> sizes (like a lot of DOS and Windows C code), then you can keep it
> working by keeping these assumptions valid in other compilers.  This is,
> I think, the reason why MS decided that long should be 32-bit on 64-bit
> Windows - it was to reduce the amount of bad code that would have to be
> changed by incompetent programmers who never understood how to write
> portable C.  (This was not helped by MS' inability to make a C99 compiler.)

If all that was needed for an assumption to be valid is be for compiler
writers to make a bona fide effort to support code that benefits from that
assumption, at least on platforms where that could be done cheaply, does
that mean such an assumption should have been viewed as "silly"?

I'd say the assumption that popular future hardware platforms would remain
capable of efficiently supporting code that relied upon 1980s-1990s types
was true.  The mistake was assuming that compiler writers would try to
avoid breaking things needlessly.  That assumption appears in retrospect to
have been wrong, but that doesn't make it unreasonable.

> Of course, this did not help for code that had other silly, unnecessary
> and invalid assumptions that Windows programmers liked to make - such as
> that pointers can fit in a "long".  It seems that MS felt that this was
> less common than the mistake of assuming "long" was 32-bit, and so that
> was the size they picked for "long".  This is despite MS having a long
> history of typedef's and macros for particular sized types.

I would expect that a lot more code relies upon having int32_t and long
share representations, than would rely upon intptr_t and long doing so.
Further, most 64-bit platforms would be able to efficiently support a mode
where the latter assumption would hold when processing code where everything
that isn't of static or automatic duration is received from functions like
malloc().  If a program never needs more than 4GB of storage, such a mode
using 32-bit pointers might be able to process some kinds of pointer-heavy
operations more efficiently than code using 64-bit pointers, since a table
of 32-bit pointers would only span half as many cache lines as a table with
the same number of 64-bit pointers.

[toc] | [prev] | [next] | [standalone]

#127698

supercat@casperkitty.com writes:
>On Monday, March 12, 2018 at 11:07:04 AM UTC-5, David Brown wrote:
>> The code would have been source-code compatible anyway - as long as
>> people don't make silly, unnecessary and invalid assumptions about sizes
>> without checking them.  And the code would never have been object code
>> compatible.
>
>A module that assumes "int" is 16 bits could be object-code compatible
>with one that assumes "int" is 32 bits if inter-module references use

Why would anyone ever possibly want such a thing?

[toc] | [prev] | [next] | [standalone]

#127700

On Monday, March 12, 2018 at 1:42:47 PM UTC-5, Scott Lurndal wrote:
> supercat@casperkitty.com writes:
> >On Monday, March 12, 2018 at 11:07:04 AM UTC-5, David Brown wrote:
> >> The code would have been source-code compatible anyway - as long as
> >> people don't make silly, unnecessary and invalid assumptions about sizes
> >> without checking them.  And the code would never have been object code
> >> compatible.
> >
> >A module that assumes "int" is 16 bits could be object-code compatible
> >with one that assumes "int" is 32 bits if inter-module references use
> 
> Why would anyone ever possibly want such a thing?

If an existing project is being migrated from a 16-bit CPU to a 32-bit CPU,
being able to have the 16-bit portions continue to work as they always
have would seem useful.  Note that because of the way C's integer promotion
rules work, code like "if ((u16a-u16b) > u16c)" or "u16c = u16a*u16b;" would
have baked-in assumptions about the size of "unsigned" even if all variables
are of the "fixed-size" type "uint16_t".  The former code snippet should
probably be flagged in a code review even when targeting a 16-bit platform
because casting the result of the subtraction to uin16_t would make the
intention clearer.  I suspect many code reviews would accept the second bit
of code in cases where a mod-65536 product was required (e.g. some hashing
calculations), even though some compilers with 32-bit "unsigned" would
jump the rails for some combinations of operands.

[toc] | [prev] | [next] | [standalone]

#127705

supercat@casperkitty.com writes:
>On Monday, March 12, 2018 at 1:42:47 PM UTC-5, Scott Lurndal wrote:
>> supercat@casperkitty.com writes:
>> >On Monday, March 12, 2018 at 11:07:04 AM UTC-5, David Brown wrote:
>> >> The code would have been source-code compatible anyway - as long as
>> >> people don't make silly, unnecessary and invalid assumptions about sizes
>> >> without checking them.  And the code would never have been object code
>> >> compatible.
>> >
>> >A module that assumes "int" is 16 bits could be object-code compatible
>> >with one that assumes "int" is 32 bits if inter-module references use
>> 
>> Why would anyone ever possibly want such a thing?
>
>If an existing project is being migrated from a 16-bit CPU to a 32-bit CPU,
>being able to have the 16-bit portions continue to work as they always
>have would seem useful.

Not to me.  It's a pointless exercise.  Save time and trouble by just porting
the damn thing to 32-bit.

[toc] | [prev] | [next] | [standalone]

#127710

On Monday, March 12, 2018 at 3:27:50 PM UTC-5, Scott Lurndal wrote:
> supercat@casperkitty.com writes:
> >If an existing project is being migrated from a 16-bit CPU to a 32-bit CPU,
> >being able to have the 16-bit portions continue to work as they always
> >have would seem useful.
> 
> Not to me.  It's a pointless exercise.  Save time and trouble by just porting
> the damn thing to 32-bit.

With regard to 16-to-32 bit migration, it's less useful now than it would
have been in the past, but the same principles would be equally applicable
when interfacing 32-bit and 64-bit code.  Even on a particular platform,
there may not be one combination of integer sizes that is optimal for all
purposes.  All a compiler would need to do to make integer sizes configurable
would be:

    1. Have fixed-sized internal types to which C's integer types are mapped,
       and make types like "int" and "long" be aliases for those types.

    2. Promote operations on values smaller than the type associated with
       "int" to that type.

    3. Have a means of adjusting the names of standard-library functions
       to versions which are configured for particular combinations of
       sizes.

    4. Build a version of the standard library for any combination of sizes
       to be supported.

If it weren't necessary to support code which uses its own prototypes for
standard-library functions, #3 and #4 could be handled at the header-file
level via e.g.

    char *__strchr(char const *restrict str, int64_t chr);
    inline char *strchr(char const *restrict str, int chr)
    { return __strchr(str, chr); };

Such a header file could then allow a single link library to support the
functions in the Standard Library for any combination of integer sizes
where "int" is no larger than the smallest integer type used for parameter
passing.

[toc] | [prev] | [next] | [standalone]

#127738

On 12/03/18 20:20, supercat@casperkitty.com wrote:
> On Monday, March 12, 2018 at 1:42:47 PM UTC-5, Scott Lurndal wrote:
>> supercat@casperkitty.com writes:
>>> On Monday, March 12, 2018 at 11:07:04 AM UTC-5, David Brown wrote:
>>>> The code would have been source-code compatible anyway - as long as
>>>> people don't make silly, unnecessary and invalid assumptions about sizes
>>>> without checking them.  And the code would never have been object code
>>>> compatible.
>>>
>>> A module that assumes "int" is 16 bits could be object-code compatible
>>> with one that assumes "int" is 32 bits if inter-module references use
>>
>> Why would anyone ever possibly want such a thing?
> 
> If an existing project is being migrated from a 16-bit CPU to a 32-bit CPU,
> being able to have the 16-bit portions continue to work as they always
> have would seem useful. 

If you wrote in C, there wouldn't /be/ 16-bit and 32-bit portions.

Now, I can agree that some aspects of the way C is designed make it easy
to make mistakes such as assumptions of sizes, and the way integer
promotion happens makes the sizes inconsistent (so a 16-bit short on a
32-bit system behaves differently from a 16-bit int on a 16-bit system).
 With 20/20 hindsight, it could have been done differently.

So it takes a bit of care to make some kinds of code independent of the
size of int - even C99 sized integer types don't eliminate all possible
issues.  But it can still be done.

Usually there are few issues in using code based on the assumption of a
16-bit int and compiling with a 32-bit int.  The typical problems are
alignment and sizeof issues - this may mean that some cases of "int"
need to be replaced with typedefs "int16_t" (or similar).  Going the
other way is more likely to be problematic.

[toc] | [prev] | [next] | [standalone]

#127686

supercat@casperkitty.com writes:
> On Saturday, March 10, 2018 at 10:39:48 AM UTC-6, David Brown wrote:
[...]
>> If you have existing code that cannot be modified, and it makes invalid 
>> assumptions that don't apply on your current target, then you can't use 
>> it.  It is that simple.
>
> So it would be impossible for a compiler targeting x64 to successfully
> process code that expects "long" to be 32 bits?  Maybe someone should tell
> Microsoft that.

Nobody said that.  Of course it's possible for an x86_64 compiler to use
32-bit long.  It's just not required.

If you write code that assumes long is exactly 32 bits, it will break
when compiled with a compiler that makes long 64 bits.  Such compilers
are common.

Are you suggesting that all x86_64 compilers *should* use 32-bit long?
If so, why?  If not, what point are you trying make?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#127693

On Monday, March 12, 2018 at 11:23:28 AM UTC-5, Keith Thompson wrote:
> Are you suggesting that all x86_64 compilers *should* use 32-bit long?
> If so, why?  If not, what point are you trying make?

I would suggest that a quality compilers should provide a mode that
would do so, at least when targeting platforms that could handle such
code efficiently.

Even if ability to use pre-existing code weren't a consideration, an
ability to have "long" be treated as 32 bits would improve the performance
of a lot of code when used in cases where a 32-bit "long" would suffice.
If a source-code program will occasionally be used on large data sets where
a 32-bit "long" would be insufficient, but would more often used on
smaller ones where it would suffice, being able to use one source text to
produce an executable that can handle big data sets as well as one which can
process smaller ones more efficiently (at the expense of being unable to
handle bigger ones) would seem useful.

[toc] | [prev] | [next] | [standalone]

#127697

On Monday, March 12, 2018 at 9:23:28 AM UTC-7, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > On Saturday, March 10, 2018 at 10:39:48 AM UTC-6, David Brown wrote:
> [...]
> >> If you have existing code that cannot be modified, and it makes invalid 
> >> assumptions that don't apply on your current target, then you can't use 
> >> it.  It is that simple.
> >
> > So it would be impossible for a compiler targeting x64 to successfully
> > process code that expects "long" to be 32 bits?  Maybe someone should tell
> > Microsoft that.
> 
> Nobody said that.  Of course it's possible for an x86_64 compiler to use
> 32-bit long.  It's just not required.
> 
> If you write code that assumes long is exactly 32 bits, it will break
> when compiled with a compiler that makes long 64 bits.  Such compilers
> are common.
> 
> Are you suggesting that all x86_64 compilers *should* use 32-bit long?
> If so, why?  If not, what point are you trying make?
 
IMO there is a natural size for int on any computer and that's
the int size that a compiler should use. But, you ask, how can
I write portable software if the int size depends on the
hardware and the hardware is unknown. Answer: You can't. 

You might start every "main" function with something like:
   if (sizeof int != 8) {
      printf ("This is 64 bit code!");
      exit (1);}
You could gimmick the compiler to do that automatically. Or
you could make that stub the universal "main" by using
a version of the statement 
   exit (real_main ( ..));

I don't really have strong feelings about this matter.

[toc] | [prev] | [next] | [standalone]

#127699

On Monday, March 12, 2018 at 1:41:19 PM UTC-5, David Kleinecke wrote:
> IMO there is a natural size for int on any computer and that's
> the int size that a compiler should use. But, you ask, how can
> I write portable software if the int size depends on the
> hardware and the hardware is unknown. Answer: You can't. 

Sure you can, if you use some type other than "int" in cases where
you care about the size, and take care to cast or coerce values whose
treatment may depend upon the size of "int".  For example, even when
targeting a 16-bit platform, using something like

   if ((uint16_t)(u16a - u16b) > 23)

to check the mod-65536 difference between u16a and u16b would make the
code clearer than if it relied upon the integer promotion rules.  When
computing a mod-65536 product, using 

   u16c = 1L * u16a * u16b;

may not really be any clearer than simply multiplying u16a*u16b, but
it will work even with compilers that would otherwise try to "optimize"
based on the assumption that u16a < 2147483647/u16b and generate code
that will sometimes fail if that isn't true.

[toc] | [prev] | [next] | [standalone]

#127592

On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote:
> Other implementations that support C99 in the compiler, support it in
> the library.

Freestanding implementations don't always have a version of printf-style
functions that would be suitable for every application's purposes.  If
an application uses its own functions for variadic formatting (whether
called printf or something else) it may get tripped up by such issues,
though in different ways from printf.

Given that the Standard does not allow variadic functions when no prototype
is visible, many such issues could have been alleviated by having a means
by which a variadic function's prototype could explicitly specify what types
of arguments it can accept.  A variadic function that does not accept any
types of integer arguments other than int64_t and uint64_t would be a little
less efficient than one which can accept smaller arguments, but could be
safely passed things like ptrdiff_t in the same manner as any other integer
type.

> Embedded toolchains for small systems might optionally have library
> versions that are missing features so that the library code is smaller.
>  This usually means printf functions without floating point support, but
> they may also omit 64-bit integer support.

Many embedded toolchains would be considered freestanding implementations,
and as such the Standard imposes no requirements on any library that might
be bundled with them, beyond those the compiler itself might use when
evaluating operators that don't map to CPU instructions [e.g. integer
division or floating-point math] which would be required to behave like
the operators in question.

[toc] | [prev] | [next] | [standalone]

#127594

supercat@casperkitty.com writes:
>On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote:
>> Other implementations that support C99 in the compiler, support it in
>> the library.
>
>Freestanding implementations don't always have a version of printf-style
>functions that would be suitable for every application's purposes. 

So do what everyone else does and grab a version of BSD's printf
and include in the codebase.

http://unix.superglobalmegacorp.com/386BSD-0.0/newsrc/stand/printf.c.html

or this one supports more format characters:

#define NBBY    8               /* number of bits in a byte */

/* Max number conversion buffer length: a uint64 in base 2, plus zero byte. */
#define MAXNBUF (sizeof(int64) * NBBY + 1)

char const hex2ascii_data[] = "0123456789abcdefghijklmnopqrstuvwxyz";

#define	hex2ascii(hex)	(hex2ascii_data[hex])

/**
 * Put a NUL-terminated ASCII number (base <= 36) in a buffer in reverse
 * order; return an optional length and a pointer to the last character
 * written in the buffer (i.e., the first character of the string).
 * The buffer pointed to by `nbuf' must have length >= MAXNBUF.
 *
 * @param nbuf	    buffer to hold the converted number.
 * @param num	    The value to be converted.
 * @param base	    The radix to be used in converting.
 * @param lenp	    A pointer to where return the pointer to the last character
 *		    written in the buffer. Specify NULL to not have this
 *		    pointer returned.
 */
static char *
ksprintn(char *nbuf, uint64 num, int base, int *lenp)
{
    char *p;

    p = nbuf;
    *p = '\0';
    do {
	*++p = hex2ascii(num % base);
    } while (num /= base);
    if (lenp)
    	*lenp = p - nbuf;
    return (p);
}


/**
 * Scaled down version of printf(3).
 *
 * Two additional formats:
 *
 * The format %b is supported to decode error registers.
 * Its usage is:
 *
 *	printf("reg=%b\n", regval, "<base><arg>*");
 *
 * where <base> is the output base expressed as a control character, e.g.
 * \10 gives octal; \20 gives hex.  Each arg is a sequence of characters,
 * the first of which gives the bit number to be inspected (origin 1), and
 * the next characters (up to a control character, i.e. a character <= 32),
 * give the name of the register.  Thus:
 *
 *	printf("reg=%b\n", 3, "\10\2BITTWO\1BITONE\n");
 *
 * would produce output:
 *
 *	reg=3<BITTWO,BITONE>
 *
 * XXX:  %D  -- Hexdump, takes pointer and separator string:
 *		("%6D", ptr, ":")   -> XX:XX:XX:XX:XX:XX
 *		("%*D", len, ptr, " " -> XX XX XX XX ...
 *
 * @param fmt	pointer to printf format string
 * @param ap	pointer to argument list
 * @param buf	pointer to buffer to receive formatted, zero terminated results
 * @param limit number of chars buf can hold, INCLUDING zero termination
 * @return int  number of chars put into buf, does NOT include zero terminator
 */
size_t
format(const char *fmt, va_list ap, char *buf, int limit)
{

/* Reserve one byte for '\0', in buffer overflow case. */
#define PCHAR(c) {int cc=(c); if (retval < (limit - 1)) {*d++ = cc; retval++;} }

    char nbuf[MAXNBUF];
    char *d = buf;
    const char *p, *percent, *q;
    uint8 *up;
    int ch, n;
    uint64 num;
    int base, lflag, qflag, tmp, width, ladjust, sharpflag, neg, sign, dot;
    int cflag, hflag, jflag, tflag, zflag;
    int dwidth;
    char padc;
    int retval = 0;

    num = 0;

    if (fmt == NULL)
    	fmt = "(fmt null)\n";

    for (;;) {
    	padc = ' ';
    	width = 0;
    	while ((ch = (uint8)*fmt++) != '%') {
    		if (ch == '\0') {
			*d++ = '\0';
			retval++;
    			return (retval);
		}
    		PCHAR(ch);
    	}
    	percent = fmt - 1;
    	qflag = 0; lflag = 0; ladjust = 0; sharpflag = 0; neg = 0;
    	sign = 0; dot = 0; dwidth = 0;
    	cflag = 0; hflag = 0; jflag = 0; tflag = 0; zflag = 0;
reswitch:   switch (ch = (uint8)*fmt++) {
		case '.':
			dot = 1;
			goto reswitch;
		case '#':
			sharpflag = 1;
			goto reswitch;
		case '+':
			sign = 1;
			goto reswitch;
		case '-':
			ladjust = 1;
			goto reswitch;
		case '%':
			PCHAR(ch);
			break;
		case '*':
			if (!dot) {
				width = va_arg(ap, int);
				if (width < 0) {
					ladjust = !ladjust;
					width = -width;
				}
			} else {
				dwidth = va_arg(ap, int);
			}
			goto reswitch;
		case '0':
			if (!dot) {
				padc = '0';
				goto reswitch;
			}
		case '1': case '2': case '3': case '4':
		case '5': case '6': case '7': case '8': case '9':
				for (n = 0;; ++fmt) {
					n = n * 10 + ch - '0';
					ch = *fmt;
					if (ch < '0' || ch > '9')
						break;
				}
			if (dot)
				dwidth = n;
			else
				width = n;
			goto reswitch;
		case 'b':
			num = (uint32)va_arg(ap, int);
			p = va_arg(ap, char *);
			for (q = ksprintn(nbuf, num, *p++, NULL); *q;)
				PCHAR(*q--);

			if (num == 0)
				break;

			for (tmp = 0; *p;) {
				n = *p++;
				if (num & (1 << (n - 1))) {
					PCHAR(tmp ? ',' : '<');
					for (; (n = *p) > ' '; ++p)
						PCHAR(n);
					tmp = 1;
				} else
					for (; *p > ' '; ++p)
						continue;
			}
			if (tmp)
				PCHAR('>');
			break;
		case 'c':
			PCHAR(va_arg(ap, int));
			break;
		case 'D':
			up = va_arg(ap, uint8 *);
			p = va_arg(ap, char *);
			if (!width)
				width = 16;
			while(width--) {
				PCHAR(hex2ascii(*up >> 4));
				PCHAR(hex2ascii(*up & 0x0f));
				up++;
				if (width)
					for (q=p;*q;q++)
						PCHAR(*q);
			}
			break;
		case 'd':
		case 'i':
			base = 10;
			sign = 1;
			goto handle_sign;
		case 'h':
			if (hflag) {
				hflag = 0;
				cflag = 1;
			} else
				hflag = 1;
			goto reswitch;
		case 'j':
			jflag = 1;
			goto reswitch;
		case 'l':
			if (lflag) {
				lflag = 0;
				qflag = 1;
			} else
				lflag = 1;
			goto reswitch;
		case 'n':
			if (jflag)
				*(va_arg(ap, int64 *)) = retval;
			else if (qflag)
				*(va_arg(ap, int64 *)) = retval;
			else if (lflag)
				*(va_arg(ap, long *)) = retval;
			else if (zflag)
				*(va_arg(ap, size_t *)) = retval;
			else if (hflag)
				*(va_arg(ap, short *)) = retval;
			else if (cflag)
				*(va_arg(ap, char *)) = retval;
			else
				*(va_arg(ap, int *)) = retval;
			break;
		case 'o':
			base = 8;
			goto handle_nosign;
		case 'p':
			base = 16;
			sharpflag = (width == 0);
			sign = 0;
			num = (uintptr_t)va_arg(ap, void *);
			goto number;
		case 'q':
			qflag = 1;
			goto reswitch;
		case 's':
			p = va_arg(ap, char *);
			if (p == NULL)
				p = "(null)";
			if (!dot)
				n = strlen (p);
			else
				for (n = 0; n < dwidth && p[n]; n++)
					continue;

			width -= n;

			if (!ladjust && width > 0)
				while (width--)
					PCHAR(padc);
			while (n--)
				PCHAR(*p++);
			if (ladjust && width > 0)
				while (width--)
					PCHAR(padc);
			break;
		case 't':
			tflag = 1;
			goto reswitch;
		case 'u':
			base = 10;
			goto handle_nosign;
		case 'x':
		case 'X':
			if (dot) {
			    padc = '0';
			}
			base = 16;
			goto handle_nosign;
		case 'y':
			base = 16;
			sign = 1;
			goto handle_sign;
		case 'z':
			zflag = 1;
			goto reswitch;
handle_nosign:
			sign = 0;
			if (jflag)
				num = va_arg(ap, uint64);
			else if (qflag)
				num = va_arg(ap, uint64);
			else if (tflag)
				num = va_arg(ap, int64);
			else if (lflag)
				num = va_arg(ap, uint64);
			else if (zflag)
				num = va_arg(ap, size_t);
			else if (hflag)
				num = (uint16)va_arg(ap, int);
			else if (cflag)
				num = (uint8)va_arg(ap, int);
			else
				num = va_arg(ap, uint32);
			goto number;
handle_sign:
			if (jflag)
				num = va_arg(ap, int64);
			else if (qflag)
				num = va_arg(ap, int64);
			else if (tflag)
				num = va_arg(ap, int64);
			else if (lflag)
				num = va_arg(ap, long);
			else if (zflag)
				num = va_arg(ap, size_t);
			else if (hflag)
				num = (short)va_arg(ap, int);
			else if (cflag)
				num = (char)va_arg(ap, int);
			else
				num = va_arg(ap, int);
number:
			if (sign && (int64)num < 0) {
				neg = 1;
				num = -(int64)num;
			}
			p = ksprintn(nbuf, num, base, &tmp);
			if (sharpflag && num != 0) {
				if (base == 8)
					tmp++;
				else if (base == 16)
					tmp += 2;
			}
			if (neg)
				tmp++;

			if (!ladjust && width && (width -= tmp) > 0)
				while (width--)
					PCHAR(padc);
			if (neg)
				PCHAR('-');
			if (sharpflag && num != 0) {
				if (base == 8) {
					PCHAR('0');
				} else if (base == 16) {
					PCHAR('0');
					PCHAR('x');
				}
			}

			while (*p)
				PCHAR(*p--);

			if (ladjust && width && (width -= tmp) > 0)
				while (width--)
					PCHAR(padc);

			break;
		default:
			while (percent < fmt)
				PCHAR(*percent++);
			break;
    	}
    }
#undef PCHAR
}

[toc] | [prev] | [next] | [standalone]

#127613

On 09/03/18 21:09, supercat@casperkitty.com wrote:
> On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote:
>> Other implementations that support C99 in the compiler, support it in
>> the library.
> 
> Freestanding implementations don't always have a version of printf-style
> functions that would be suitable for every application's purposes.  If
> an application uses its own functions for variadic formatting (whether
> called printf or something else) it may get tripped up by such issues,
> though in different ways from printf.
> 
> Given that the Standard does not allow variadic functions when no prototype
> is visible, many such issues could have been alleviated by having a means
> by which a variadic function's prototype could explicitly specify what types
> of arguments it can accept.  A variadic function that does not accept any
> types of integer arguments other than int64_t and uint64_t would be a little
> less efficient than one which can accept smaller arguments, but could be
> safely passed things like ptrdiff_t in the same manner as any other integer
> type.
> 
>> Embedded toolchains for small systems might optionally have library
>> versions that are missing features so that the library code is smaller.
>>   This usually means printf functions without floating point support, but
>> they may also omit 64-bit integer support.
> 
> Many embedded toolchains would be considered freestanding implementations,
> and as such the Standard imposes no requirements on any library that might
> be bundled with them, beyond those the compiler itself might use when
> evaluating operators that don't map to CPU instructions [e.g. integer
> division or floating-point math] which would be required to behave like
> the operators in question.
> 

Your ideas about embedded toolchains are as fantastical as your ideas 
about the standards and about other C implementations.

[toc] | [prev] | [next] | [standalone]

#127679

On Saturday, March 10, 2018 at 11:35:17 AM UTC-6, David Brown wrote:
> On 09/03/18 21:09, supercat@casperkitty.com wrote:
> > Many embedded toolchains would be considered freestanding implementations,
> > and as such the Standard imposes no requirements on any library that might
> > be bundled with them, beyond those the compiler itself might use when
> > evaluating operators that don't map to CPU instructions [e.g. integer
> > division or floating-point math] which would be required to behave like
> > the operators in question.
> 
> Your ideas about embedded toolchains are as fantastical as your ideas 
> about the standards and about other C implementations.

If a target platform lacks any means of specifying command-line
arguments, performing any kind of file or console I/O, or even
requesting memory allocations at run-time, would it really be
proper to call an implementation targeting it a "hosted" one?
Or would it make more sense to describe implementations that target
such platforms as "freestanding"?

Certainly many (probably most) implementations that target such
platforms do support much of the Standard Library, but the Standard
explicitly does not *require* that freestanding implementations do
so.  If a freestanding implementation which targeted a "bare-metal" CPU
with no floating-point unit would process something like

    double result=float1 * double1;

into code equivalent to something like:

    __fpLoadFloat(&float1);
    __fpMulDouble(&double1);
    __fpStoreDouble(&result);

it would be obligated to include implementations of the fpLoadFloat(),
fpMulDouble(), and fpStoreDouble() functions.  I see nothing in the
Standard that would require it bundle code for any Standard Library
functions, however.

[toc] | [prev] | [next] | [standalone]

#127732

On 12/03/18 16:54, supercat@casperkitty.com wrote:
> On Saturday, March 10, 2018 at 11:35:17 AM UTC-6, David Brown wrote:
>> On 09/03/18 21:09, supercat@casperkitty.com wrote:
>>> Many embedded toolchains would be considered freestanding implementations,
>>> and as such the Standard imposes no requirements on any library that might
>>> be bundled with them, beyond those the compiler itself might use when
>>> evaluating operators that don't map to CPU instructions [e.g. integer
>>> division or floating-point math] which would be required to behave like
>>> the operators in question.
>>
>> Your ideas about embedded toolchains are as fantastical as your ideas 
>> about the standards and about other C implementations.
> 
> If a target platform lacks any means of specifying command-line
> arguments, performing any kind of file or console I/O, or even
> requesting memory allocations at run-time, would it really be
> proper to call an implementation targeting it a "hosted" one?
> Or would it make more sense to describe implementations that target
> such platforms as "freestanding"?

A "hosted" environment is one where there is an OS providing services,
library, filesystem, etc., separate from the application code.  A
"freestanding" environment is missing at least some of that.  It is up
to the implementation to decide if it is hosted or freestanding, and
freestanding implementations don't need much of the standard library to
be conforming.

In practice, most embedded toolchains are freestanding - and yet most of
them provide as much of the standard library as they can (possibly
requiring user-defined hooks to actually output characters from printf,
and that sort of thing).

They invariably provide full printf and friends (to the extent that they
are conforming compilers - an embedded compiler with a 32-bit "double"
would not support 64-bit floating point printf output).  They sometimes
have optional extra libraries of reduced features and size.

> 
> Certainly many (probably most) implementations that target such
> platforms do support much of the Standard Library, but the Standard
> explicitly does not *require* that freestanding implementations do
> so.

I know that.  So do most people, I think.  So what?  There are lots of
things that the standards don't require but which useful implementations
provide.

>  If a freestanding implementation which targeted a "bare-metal" CPU
> with no floating-point unit would process something like
> 
>     double result=float1 * double1;
> 
> into code equivalent to something like:
> 
>     __fpLoadFloat(&float1);
>     __fpMulDouble(&double1);
>     __fpStoreDouble(&result);
> 
> it would be obligated to include implementations of the fpLoadFloat(),
> fpMulDouble(), and fpStoreDouble() functions.  

That is true of freestanding and hosted implementations, and such
functions are not part of the C standard library.  These are part of
what is usually termed the "language support library" - a library of
functions needed for the language itself, not for the standard library.
 (For example, in gcc this is usually provided directly by gcc rather
than from a separate source, such as newlib, like the C standard library.)

There is nothing "freestanding" about the use of such functions.

> I see nothing in the
> Standard that would require it bundle code for any Standard Library
> functions, however.
> 

The standard library headers which freestanding implementations are
required to provide to be conforming are header-only files - there is no
need for any library code behind them.

In reality, /all/ embedded toolchains come with an extensive library
covering as much of the standard library as practically possible, and
often containing other functions the vendor deems useful.

[toc] | [prev] | [next] | [standalone]

#127953

Keith Thompson <kst-u@mib.org> writes:

> supercat@casperkitty.com writes:
>
>> [one of his typical philippics]
>
> Are you seriously advocating writing code that assumes long is exactly
> 32 bits?  Will you at least acknowledge that such code would break on
> many modern systems?  How is the readability of code that doesn't work
> relevant?
>
> I'm just about to give up trying to understand whatever point you're
> trying to make.

He doesn't have one.  He's unhappy that the real world doesn't
match his fantasy world, which it never well, but that drawback
notwithstanding he continues his quixotic quest to square the
circle.  I advise adding him to your killfile and/or simply not
reading whatever he writes.  You'll be happier after you do.  I
know I have been.

[toc] | [prev] | [next] | [standalone]

#127625

On 08/03/2018 17:59, supercat@casperkitty.com wrote:

...

> Which of the following would you consider more legible:
> 
>       uint32_t x,y; uint16_t small; uint64_t big
>       printf("x=%ld y=%ld small=%d big=%lld", x, y, small, big);
> or
>       printf("x=%" PRId32 " y=%" PRId32 " small=%" PRId16 " big=%" PRId64,
>              x, y, small, big);

While agreeing with your basic point that such macros are ugly they can 
be split into separate statements such as

       printf("x=%" PRId32, x);
       printf(" y=%" PRId32, y);
       printf(" small=%" PRId16, small);
       printf(" big=%" PRId64, big);

That's legible and portable.


-- 
James Harris

[toc] | [prev] | [next] | [standalone]

#127641

On Saturday, March 10, 2018 at 11:37:20 PM UTC-8, James Harris wrote:
> On 08/03/2018 17:59, supercat@casperkitty.com wrote:
> 
> ...
> 
> > Which of the following would you consider more legible:
> > 
> >       uint32_t x,y; uint16_t small; uint64_t big
> >       printf("x=%ld y=%ld small=%d big=%lld", x, y, small, big);
> > or
> >       printf("x=%" PRId32 " y=%" PRId32 " small=%" PRId16 " big=%" PRId64,
> >              x, y, small, big);
> 
> While agreeing with your basic point that such macros are ugly they can 
> be split into separate statements such as
> 
>        printf("x=%" PRId32, x);
>        printf(" y=%" PRId32, y);
>        printf(" small=%" PRId16, small);
>        printf(" big=%" PRId64, big);
> 
> That's legible and portable.
 
I dunno. What about
    printf("x=%ld", x);
    printf(" y=%ld", y);
    printf(" small=%d", small);
    printf(" big=%lld", big);
?

[toc] | [prev] | [next] | [standalone]

#127643

On Sun, 11 Mar 2018 14:22:02 -0700 (PDT)
David Kleinecke <dkleinecke@gmail.com> wrote:
> On Saturday, March 10, 2018 at 11:37:20 PM UTC-8, James Harris wrote:
> > On 08/03/2018 17:59, supercat@casperkitty.com wrote:
> > 
> > ...
> > 
> > > Which of the following would you consider more legible:
> > > 
> > >       uint32_t x,y; uint16_t small; uint64_t big
> > >       printf("x=%ld y=%ld small=%d big=%lld", x, y, small, big);
> > > or
> > >       printf("x=%" PRId32 " y=%" PRId32 " small=%" PRId16 " big=%" PRId64,
> > >              x, y, small, big);
> > 
> > While agreeing with your basic point that such macros are ugly they can 
> > be split into separate statements such as
> > 
> >        printf("x=%" PRId32, x);
> >        printf(" y=%" PRId32, y);
> >        printf(" small=%" PRId16, small);
> >        printf(" big=%" PRId64, big);
> > 
> > That's legible and portable.

PRId*  are for signed integers ; correct are  PRIu* .

>  
> I dunno. What about
>     printf("x=%ld", x);
>     printf(" y=%ld", y);
>     printf(" small=%d", small);
>     printf(" big=%lld", big);
> ?

Each one of your constructs is undefined behaviour. For example  %ld  is for
long int  which is signed and will be at least 32 bit but could be more
whereas  uint32_t  is unsigned and has exactly 32 bit.

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web