L_tmpnam macro

[Bob Nelson]

Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?

Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

[Bob Nelson]

Re: L_tmpnam macro

Bob Nelson wrote:

Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?
[...]

My botch: ``s/7.7.4/7.9.4/''.

[Keith Thompson]

Re: L_tmpnam macro

Bob Nelson <bnelson@nelson be.comwrites:

Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?

You mean 7.9.1/7.9.4.4. Both refer to sections in the C90 standard.

I presume it was deliberate. The uppercase 'L' partially follows the
convention of uppercase macro names. The lowercase "tmpnam" refers to
the tmpnam() function.

Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

No, here's another one:

#define the_answer 42

But seriously, C99's <stdbool.hhas macros "false", "true", and
"__bool_true_fa lse_are_defined ". Those are the only ones I can think
of. If you're more interested in the answer than I am 8-)}, you can
always look through the standard for other examples.

--
Keith Thompson (The_Other_Keit h) 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"

[pete]

Re: L_tmpnam macro

Bob Nelson wrote:

Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
deliberate design decision?
>
Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

In C89 there's also:
offsetof
stdin
stdout
stderr
assert
errno
va_start
va_arg
va_copy

C99 has more.

--
pete

[Richard Bos]

Re: L_tmpnam macro

pete <pfiland@mindsp ring.comwrote:

Bob Nelson wrote:

Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

>
In C89 there's also:
offsetof
stdin
stdout
stderr
assert
errno
va_start
va_arg
va_copy

None of those expand to an integral _constant_ expression.

Richard

[Richard Heathfield]

Re: L_tmpnam macro

pete said:

Bob Nelson wrote:

>Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
>deliberate design decision?
>>
>Is it the only macro expanding to an integral constant expression that
>has lowercase characters in the name?

>
In C89 there's also:
offsetof
stdin

That doesn't look like any kind of integral constant expression to me.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Tobin]

Re: L_tmpnam macro

In article <484e5ca6.10322 42115@news.xs4a ll.nl>,
Richard Bos <rlb@hoekstra-uitgeverij.nlwr ote:

Is it the only macro expanding to an integral constant expression that has
lowercase characters in the name?

>In C89 there's also:
>offsetof
>stdin
>stdout
>stderr
>assert
>errno
>va_start
>va_arg
>va_copy

>None of those expand to an integral _constant_ expression.

offsetof does.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[pete]

Re: L_tmpnam macro

Richard Tobin wrote:

In article <484e5ca6.10322 42115@news.xs4a ll.nl>,
Richard Bos <rlb@hoekstra-uitgeverij.nlwr ote:
>

>>>Is it the only macro expanding to an integral constant expression that has
>>>lowercase characters in the name?

>

>>In C89 there's also:
>>offsetof
>>stdin
>>stdout
>>stderr
>>assert
>>errno
>>va_start
>>va_arg
>>va_copy

>

>None of those expand to an integral _constant_ expression.

Oops!

>
offsetof does.

--
pete

[Bob Nelson]

Re: L_tmpnam macro

Keith Thompson wrote:

Bob Nelson <bnelson@nelson be.comwrites:

>Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
>deliberate design decision?

>
You mean 7.9.1/7.9.4.4. Both refer to sections in the C90 standard.
>
I presume it was deliberate. The uppercase 'L' partially follows the
convention of uppercase macro names. The lowercase "tmpnam" refers to
the tmpnam() function.

And what of ``fopen_MAX'' where the lowercase ``fopen'' refers to the
fopen() function?

Hmmm...that macro is, of course, ``FOPEN_MAX''. So why was similar naming
convention not used with ``L_TMPNAM''?

(I think that ``L_tmpnam'' is singular as the only macro defined by the
language using mixed case.)

[Keith Thompson]

Re: L_tmpnam macro

Bob Nelson <bnelson@nelson be.comwrites:

Keith Thompson wrote:

>Bob Nelson <bnelson@nelson be.comwrites:

>>Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by a
>>deliberate design decision?

>>
>You mean 7.9.1/7.9.4.4. Both refer to sections in the C90 standard.
>>
>I presume it was deliberate. The uppercase 'L' partially follows the
>convention of uppercase macro names. The lowercase "tmpnam" refers to
>the tmpnam() function.

>
And what of ``fopen_MAX'' where the lowercase ``fopen'' refers to the
fopen() function?
>
Hmmm...that macro is, of course, ``FOPEN_MAX''. So why was similar naming
convention not used with ``L_TMPNAM''?

Because the C standard is not an absolutely coherent document
describing a perfect language designed by superhumans. The language
was designed by very smart people (mostly one very smart person) who
make mistakes. Parts of the library were designed by different people
in different places, who didn't necessarily consult with each other.
The standard committee had the job of tying all this together into a
single document that everyone could agree on.

It's remarkable that it's as consistent and coherent as it is.

(I think that ``L_tmpnam'' is singular as the only macro defined by the
language using mixed case.)

Nope.

C99's <complex.hhas _Complex_I, and optionally _Imaginary_I.

C99's <inttypes.hdefi nes a large number of macros for format
specifiers that use mixed case (e.g., PRIdMAX to print an intmax_t
value in decimal).

I found these simply by looking at the beginning of each subsection of
section 7 of the standard (or rather, of the latest draft, available
at <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.

--
Keith Thompson (The_Other_Keit h) 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"

[Bob Nelson]

Re: L_tmpnam macro

Keith Thompson wrote:

Bob Nelson <bnelson@nelson be.comwrites:

>Keith Thompson wrote:

>>Bob Nelson <bnelson@nelson be.comwrites:
>>>Was the ``L_tmpnam'' [7.9.1/7.4.4] macro given that mixed case name by
>>>a deliberate design decision?
>>>
>>You mean 7.9.1/7.9.4.4. Both refer to sections in the C90 standard.
>>>
>>I presume it was deliberate. The uppercase 'L' partially follows the
>>convention of uppercase macro names. The lowercase "tmpnam" refers to
>>the tmpnam() function.

>>
>And what of ``fopen_MAX'' where the lowercase ``fopen'' refers to the
>fopen() function?
>>
>Hmmm...that macro is, of course, ``FOPEN_MAX''. So why was similar naming
>convention not used with ``L_TMPNAM''?

>
Because the C standard is not an absolutely coherent document
describing a perfect language designed by superhumans. The language
was designed by very smart people (mostly one very smart person) who
make mistakes. Parts of the library were designed by different people
in different places, who didn't necessarily consult with each other.
The standard committee had the job of tying all this together into a
single document that everyone could agree on.
>
It's remarkable that it's as consistent and coherent as it is.

Yes indeed, as Dennis Richie stated: ``C is quirky, flawed and an enormous
success.'' Although I don't think it necessarily takes ``superhuman''
designers to be consistent in the naming style of macros, a dose of
pedantry could have helped in this regard. :-)

>(I think that ``L_tmpnam'' is singular as the only macro defined by the
>language using mixed case.)

>
Nope.
>
C99's <complex.hhas _Complex_I, and optionally _Imaginary_I.
>
C99's <inttypes.hdefi nes a large number of macros for format
specifiers that use mixed case (e.g., PRIdMAX to print an intmax_t
value in decimal).

After reviewing both the C99 draft and ISO/IEC 9899:1990, the statement can
be modified as follow (modulo something I overlooked in my reading):

I think that ``L_tmpnam'' is the only macro defined by the language using
mixed case AND expanding to an integral constant.

[Keith Thompson]

Re: L_tmpnam macro

Bob Nelson <bnelson@nelson be.comwrites:

Keith Thompson wrote:

>Bob Nelson <bnelson@nelson be.comwrites:

[...]

>>Hmmm...that macro is, of course, ``FOPEN_MAX''. So why was similar naming
>>convention not used with ``L_TMPNAM''?

>>
>Because the C standard is not an absolutely coherent document
>describing a perfect language designed by superhumans. The language
>was designed by very smart people (mostly one very smart person) who
>make mistakes. Parts of the library were designed by different people
>in different places, who didn't necessarily consult with each other.
>The standard committee had the job of tying all this together into a
>single document that everyone could agree on.
>>
>It's remarkable that it's as consistent and coherent as it is.

>
Yes indeed, as Dennis Richie stated: ``C is quirky, flawed and an enormous
success.'' Although I don't think it necessarily takes ``superhuman''
designers to be consistent in the naming style of macros, a dose of
pedantry could have helped in this regard. :-)

The problem, I think, is that the library is a collection of pieces
developed by different people. L_tmpnam, by itself, is a reasonably
sensible name -- and by the time it was merged with the other pieces
to form what we know as the standard library, changing the name to fit
a consistent naming scheme would have broken existing code.

[snip]

--
Keith Thompson (The_Other_Keit h) 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"

[Serve Lau]

Re: L_tmpnam macro


"Keith Thompson" <kst-u@mib.orgschree f in bericht
news:lny75clbjr .fsf@nuthaus.mi b.org...

The problem, I think, is that the library is a collection of pieces
developed by different people. L_tmpnam, by itself, is a reasonably
sensible name -- and by the time it was merged with the other pieces
to form what we know as the standard library, changing the name to fit
a consistent naming scheme would have broken existing code.

Since it wasnt standardized yet changing the name would not break existing
code anymore than if they took a different name from another library. On top
of that it would only break if the name was defined in a standard header and
the final standard did not have this name. If they used their own header
there would be no problem so I dont think breaking code was the issue here,
just miscommunicatio n or an oversight or something. No biggie anyway

[Eric Sosman]

Re: L_tmpnam macro

Serve Lau wrote:

>
"Keith Thompson" <kst-u@mib.orgschree f in bericht
news:lny75clbjr .fsf@nuthaus.mi b.org...

>The problem, I think, is that the library is a collection of pieces
>developed by different people. L_tmpnam, by itself, is a reasonably
>sensible name -- and by the time it was merged with the other pieces
>to form what we know as the standard library, changing the name to fit
>a consistent naming scheme would have broken existing code.

>
Since it wasnt standardized yet changing the name would not break
existing code anymore than if they took a different name from another
library. [...]

Um, er, WHAT??!

Are you claiming that no C code existed before 1989?
That ANSI decided to write a standard for a language that
had not yet been used, or had been used only for throwaway
programs of no importance?

L_tmpnam -- and printf, and gets, and int, and ...
are older than any C language standard, and were in use
long before a standard appeared on the scene.

(Something about this reminds me of the story of the
guy who tripped and fell heavily next to a seismometer,
causing a devastating earthquake in East Berzerkistan. Or
the story of the city slicker on his first visit to a hog
farm, watching the pigs being slopped and remarking "No
wonder they're called `pigs'.")

--
Eric Sosman
esosman@ieee-dot-org.invalid

[Richard Tobin]

Re: L_tmpnam macro

In article <b62da$4853be70 $541fc2ec$16132 @cache3.tilbu1. nb.home.nl>,
Serve Lau <nihao@qinqin.c omwrote:

>The problem, I think, is that the library is a collection of pieces
>developed by different people. L_tmpnam, by itself, is a reasonably
>sensible name -- and by the time it was merged with the other pieces
>to form what we know as the standard library, changing the name to fit
>a consistent naming scheme would have broken existing code.

>Since it wasnt standardized yet changing the name would not break existing
>code anymore than if they took a different name from another library.

You might as well say that as C wasn't standardised yet, changing it
to be Fortran would not have broken any existing programs.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)