Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.std.c > #595 > unrolled thread
| Started by | "Greg A. Woods" <woods@robohack.org> |
|---|---|
| First post | 2011-07-06 19:58 -0700 |
| Last post | 2011-07-09 20:30 +0100 |
| Articles | 6 on this page of 66 — 14 participants |
Back to article view | Back to comp.std.c
PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-06 19:58 -0700
Re: PRI* considered harmful William Ahern <william@wilbur.25thandClement.com> - 2011-07-06 20:38 -0700
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-06 22:26 -0700
Re: PRI* considered harmful Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-07 08:52 +0200
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-07 14:11 -0700
Re: PRI* considered harmful Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-08 11:58 +0200
Re: PRI* considered harmful lawrence.jones@siemens.com - 2011-07-07 17:58 -0400
Re: PRI* considered harmful Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-08 12:02 +0200
Re: PRI* considered harmful lawrence.jones@siemens.com - 2011-07-07 17:57 -0400
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-07 15:42 -0700
Re: PRI* considered harmful lawrence.jones@siemens.com - 2011-07-08 08:56 -0400
Re: PRI* considered harmful James Kuyper <jameskuyper@verizon.net> - 2011-07-07 06:36 -0400
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-07 12:59 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-07 14:12 -0700
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-07 15:49 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-07 16:46 -0700
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-07 18:26 -0700
Re: PRI* considered harmful James Kuyper <jameskuyper@verizon.net> - 2011-07-07 22:35 -0400
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-07 20:58 -0700
Re: PRI* considered harmful Wojtek Lerch <wojtek_l@yahoo.ca> - 2011-07-08 00:28 -0400
Re: PRI* considered harmful James Kuyper <jameskuyper@verizon.net> - 2011-07-08 07:41 -0400
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-08 23:05 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-09 00:50 -0700
Re: [incorrectly implementd] PRI* considered harmful James Kuyper <jameskuyper@verizon.net> - 2011-07-09 06:38 -0400
Re: PRI* considered harmful Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2011-07-09 21:07 +0200
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-08 09:52 -0700
Re: PRI* considered harmful Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-08 11:45 +0100
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-08 23:14 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-09 00:47 -0700
Re: PRI* considered harmful Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-09 10:51 +0100
Re: PRI* considered harmful James Kuyper <jameskuyper@verizon.net> - 2011-07-09 06:43 -0400
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-08 09:49 -0700
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-08 23:24 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-09 00:45 -0700
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-09 16:18 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-09 18:57 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-13 09:37 -0700
Re: PRI* considered harmful James Kuyper <jameskuyper@verizon.net> - 2011-07-09 06:46 -0400
Re: PRI* considered harmful Harald van Dijk <truedfx@gmail.com> - 2011-07-09 08:09 -0700
Re: PRI* considered harmful Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-11 16:00 +0300
Re: PRI* considered harmful Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2011-07-09 20:59 +0200
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-09 12:22 -0700
Re: PRI* considered harmful Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2011-07-09 21:32 +0200
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-09 12:54 -0700
Re: PRI* considered harmful Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-09 23:39 +0200
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-09 16:56 -0700
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-09 16:52 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-09 18:53 -0700
Re: PRI* considered harmful Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-10 14:12 +0200
Re: PRI* considered harmful Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-11 20:22 +0200
Re: PRI* considered harmful Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-10 13:57 +0200
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-09 16:49 -0700
Re: PRI* considered harmful Jens Schweikhardt <usenet@schweikhardt.net> - 2011-07-19 19:28 +0000
Re: PRI* considered harmful Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-07 14:13 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-09 01:04 -0700
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-09 17:23 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-09 19:03 -0700
Re: PRI* considered harmful Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-11 20:40 +0200
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-11 11:56 -0700
Re: PRI* considered harmful Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-11 21:40 +0200
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-11 13:16 -0700
Re: PRI* considered harmful Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-11 23:29 +0200
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-11 14:46 -0700
Re: PRI* considered harmful "Greg A. Woods" <woods@robohack.org> - 2011-07-12 22:18 -0700
Re: PRI* considered harmful Keith Thompson <kst-u@mib.org> - 2011-07-13 09:00 -0700
Re: PRI* considered harmful Richard Kettlewell <rjk@greenend.org.uk> - 2011-07-09 20:30 +0100
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-07-11 13:16 -0700 |
| Message-ID | <lnliw4vaic.fsf@nuthaus.mib.org> |
| In reply to | #716 |
Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> writes:
> Keith Thompson wrote:
>> Marcin Grzegorczyk<mgrzegor@poczta.onet.pl> writes:
> [...]
>>> That's why I'd rather propose, instead of size, an enumeration with
>>> distinct (implementation-defined) values for each valid type supported
>>> by the implementation. A standardized macro could then map expression
>>> type to an enumeration constant via the C1X generic selection construct
>>> (i.e. no compiler magic needed); as an added benefit, the macro would
>>> catch cases when a completely wrong type, like a floating-point or
>>> structure type, is passed to a specifier that expects only integer types.
>>
>> But that wouldn't handle user-defined integer types, something that
>> Greg's original proposal was *intended* to do.
>
> What user-defined types wouldn't it handle? Typedefs are just aliases
> for existing types.
The point is that you don't know *which* existing type a given type is
an alias for.
Suppose a library defines a typedef "foo_t" in a header <foo.h>.
You know it's a signed integer type, and you can determine that
it's 32 bits, which could match either int or long on your system.
If you want to print a foo_t value without converting it, do you use
"%d" or "%ld"? (If the library author was kind enough to provide a
PRIFOOd macro, you can use that, but I don't know of any libraries
that do that.)
Of course you can always cast to intmax_t and use "%jd", but then
you don't really need any of the PRI* macros.
>> I'm not sure I see the benefit of the enumeration. It seems like
>> just another set of semi-arbitrary names associated with each
>> integer type.
>
> Yes, hence the standard would not need to list those names, just define
> a macro to map, in an implementation-defined manner, types to values
> expected by *printf(). In fact, you're right that enumeration is not
> necessary; a plain int would suffice.
I don't see how such a macro would work (unless it uses compiler magic,
but in that case it isn't really a macro). Or am I missing something?
> [...]
>> but if I were designing C from scratch, I'd want to have a mechanism
>> for determining all these things from the type name itself (and it
>> could also be applied to an expression of the type).
>>
>> Ada, for example, has something called "attributes", whose syntax
>> is a prefix, followed by an apostrophe, followed by a predefined
>> attribute name. The maximum values of types Character, Integer, and
>> Float are Character'Last, Integer'Last, and Float'Last, respectively.
>
> D has something similar called properties, with a much more C-like syntax:
>
> int foo;
> long bar;
> /* ... */
> if (bar > foo.max) /* ... */
>
> But then, D actually is intended to be C designed from scratch :-)
That could work. Of course you'd have to avoid collisions between
property names and struct/union member names. Are the property
names reserved? It could be confusing for "foo.max" to mean the
maximum value of foo's type (when foo is an integer expression)
and the "max" member (when foo is a struct expression).
Personally, I'd prefer to see a unique new syntax, but C makes such
heavy use of punctuation it's hard to come up with one that doesn't
break existing code. "foo$max" might work, except that '$' in
identifiers is a common extension on VMS.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> |
|---|---|
| Date | 2011-07-11 23:29 +0200 |
| Message-ID | <ivfpvs$ie1$1@dont-email.me> |
| In reply to | #717 |
Keith Thompson wrote:
> Marcin Grzegorczyk<mgrzegor@poczta.onet.pl> writes:
>> Keith Thompson wrote:
>>> Marcin Grzegorczyk<mgrzegor@poczta.onet.pl> writes:
>> [...]
>>>> That's why I'd rather propose, instead of size, an enumeration with
>>>> distinct (implementation-defined) values for each valid type supported
>>>> by the implementation. A standardized macro could then map expression
>>>> type to an enumeration constant via the C1X generic selection construct
>>>> (i.e. no compiler magic needed); as an added benefit, the macro would
>>>> catch cases when a completely wrong type, like a floating-point or
>>>> structure type, is passed to a specifier that expects only integer types.
>>>
>>> But that wouldn't handle user-defined integer types, something that
>>> Greg's original proposal was *intended* to do.
>>
>> What user-defined types wouldn't it handle? Typedefs are just aliases
>> for existing types.
>
> The point is that you don't know *which* existing type a given type is
> an alias for.
But the whole point is to make it possible to pass information about
argument types to printf without knowing what the types are, isn't it?
[...]
>>> I'm not sure I see the benefit of the enumeration. It seems like
>>> just another set of semi-arbitrary names associated with each
>>> integer type.
>>
>> Yes, hence the standard would not need to list those names, just define
>> a macro to map, in an implementation-defined manner, types to values
>> expected by *printf(). In fact, you're right that enumeration is not
>> necessary; a plain int would suffice.
>
> I don't see how such a macro would work (unless it uses compiler magic,
> but in that case it isn't really a macro). Or am I missing something?
The macro could be defined like this:
#define TYPE_ID(expr) _Generic((expr), \
int : 0, \
unsigned int : 1, \
long : 2, \
unsigned long : 3, \
/* etc. */ )
That's the C1X generic selection construct. Of course, a real
implementation would use an enumeration or a set of #defines instead of
plain 0, 1, 2, 3 etc.
Then the new 'S' printf modifier (hmm, perhaps 'T' would match the
semantics better) could be used like this:
#define INTPARAM(arg) TYPE_ID(arg), arg
printf("%Ti", INTPARAM(foo));
>> [...]
>>> Ada, for example, has something called "attributes", whose syntax
>>> is a prefix, followed by an apostrophe, followed by a predefined
>>> attribute name. The maximum values of types Character, Integer, and
>>> Float are Character'Last, Integer'Last, and Float'Last, respectively.
>>
>> D has something similar called properties, with a much more C-like syntax:
>>
>> int foo;
>> long bar;
>> /* ... */
>> if (bar> foo.max) /* ... */
>>
>> But then, D actually is intended to be C designed from scratch :-)
>
> That could work. Of course you'd have to avoid collisions between
> property names and struct/union member names. Are the property
> names reserved? It could be confusing for "foo.max" to mean the
> maximum value of foo's type (when foo is an integer expression)
> and the "max" member (when foo is a struct expression).
AFAICT they are reserved only if they apply to the type (for example,
all types have .sizeof and .alignof properties, but only floating-point
types have an .epsilon property). Yes, it can be confusing.
--
Marcin Grzegorczyk
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-07-11 14:46 -0700 |
| Message-ID | <lnhb6sv6cj.fsf@nuthaus.mib.org> |
| In reply to | #719 |
Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> writes:
> Keith Thompson wrote:
[...]
>> I don't see how such a macro would work (unless it uses compiler magic,
>> but in that case it isn't really a macro). Or am I missing something?
>
> The macro could be defined like this:
>
> #define TYPE_ID(expr) _Generic((expr), \
> int : 0, \
> unsigned int : 1, \
> long : 2, \
> unsigned long : 3, \
> /* etc. */ )
>
> That's the C1X generic selection construct. Of course, a real
> implementation would use an enumeration or a set of #defines instead of
> plain 0, 1, 2, 3 etc.
>
> Then the new 'S' printf modifier (hmm, perhaps 'T' would match the
> semantics better) could be used like this:
>
> #define INTPARAM(arg) TYPE_ID(arg), arg
>
> printf("%Ti", INTPARAM(foo));
Yes, I was indeed missing something.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "Greg A. Woods" <woods@robohack.org> |
|---|---|
| Date | 2011-07-12 22:18 -0700 |
| Message-ID | <871uxubvwl.fsf@once.weird.com> |
| In reply to | #716 |
Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> writes: > Keith Thompson wrote: >> Marcin Grzegorczyk<mgrzegor@poczta.onet.pl> writes: > [...] >>> That's why I'd rather propose, instead of size, an enumeration with >>> distinct (implementation-defined) values for each valid type supported >>> by the implementation. A standardized macro could then map expression >>> type to an enumeration constant via the C1X generic selection construct >>> (i.e. no compiler magic needed); as an added benefit, the macro would >>> catch cases when a completely wrong type, like a floating-point or >>> structure type, is passed to a specifier that expects only integer types. >> >> But that wouldn't handle user-defined integer types, something that >> Greg's original proposal was *intended* to do. > > What user-defined types wouldn't it handle? Typedefs are just aliases > for existing types. Well, IFF there were some language magic something like typeof(), but which returned an enum usable in libc's printf(), i.e. such that printf() didn't have to be recompiled to use user-defined typedefs.... I.e. I to do what you're suggesting something new is needed in the language, even beyond typeof(). [a different form of typeof()]. What really matters to printf() though, from an implementation point of view, is just how many bytes to pull off the stack, and how many bits are significant in those bytes, and what and where the sign bit is, if any. The printf() implementation doesn't need to care what the actual type is, no matter whether it's a typedef or a base type. It might be easier to write a portable printf() if you can let the compiler put those bytes back into the same base type for printf() to use, but that's not _really_ important. My suggestion uses the non-standard typeof(), but only to figure out in a portable way whether an integer rvalue is signed or not. Adding an enum of base integer types might stretch the language definition too far for most folks, whereas typeof() is, I think, relatively well known and understood, and does nothing much more than provide a way of doing "dynamic" casts. Which reminds me -- I need to find out if anyone has figured out how the proposed "AIR" integer model is works with printf(), or if it even can. -- Greg A. Woods RoboHack <woods@robohack.ca> living on the edge http://www.robohack.ca/
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-07-13 09:00 -0700 |
| Message-ID | <lnsjqarx0k.fsf@nuthaus.mib.org> |
| In reply to | #723 |
"Greg A. Woods" <woods@robohack.org> writes:
[...]
> What really matters to printf() though, from an implementation point of
> view, is just how many bytes to pull off the stack, and how many bits
> are significant in those bytes, and what and where the sign bit is, if
> any. The printf() implementation doesn't need to care what the actual
> type is, no matter whether it's a typedef or a base type. It might be
> easier to write a portable printf() if you can let the compiler put
> those bytes back into the same base type for printf() to use, but that's
> not _really_ important.
[...]
In most, perhaps all, real implementations that's true. But in
principle, an implementation could have, for example, two integer
types with identical sizes, but different representations -- for
example, one is 2's-complement and the other is sign-and-magnitude.
Requiring printf to work correctly given just size and signedness
information would require changing the standard's requirements for
type representation and argument passing mechanisms. That *might*
be acceptable, but it would require substantial time and effort to
work out all the implications.
And given that the current printf mechanism works reasonably well,
I doubt that the committee would consider it to be worth the effort.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Richard Kettlewell <rjk@greenend.org.uk> |
|---|---|
| Date | 2011-07-09 20:30 +0100 |
| Message-ID | <87oc13i74w.fsf@araminta.anjou.terraraq.org.uk> |
| In reply to | #595 |
"Greg A. Woods" <woods@robohack.org> writes: > Does anyone else think this would be worthwhile? Better ideas anyone? The right answer, if one was starting from scratch, would be the one C# (among others) has adopted: a varargs function can discover at runtime the number and type of the objects passed to it. I don't think there's any reason in principle that would be have been impossible to add to C, but it seems to me that C89 (i.e. the invention of <stdarg.h>) was probably the last realistic opportunity, and even then it would be an ABI break, making it a difficult sell. -- http://www.greenend.org.uk/rjk/
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.std.c
csiph-web