🚀 go-pugleaf

In <3vo921$n4a@pheidippides.axion.bt.co.uk> thomasgd@boat.bt.com (Greg Thomas) writes:

>Hi,
>
>I'm trying to porting some code to Alpha/DEC 'C' from VAX/VAX 'C'. We have, 
>however, hit a problem with the <errno.h> include file. It #defines it to be 
>(*cma$tis_errno_get_addr()). The trouble is, we have number of structures that 
>have an errno as an element. Of course, this gets expanded to the above 
>function, and so it won't compile. ie ...
>
You got precisely what you deserved.

>Now whilst I can change all our code to not refer to errno in this structure, 
>I feel that the DEC 'C' errno.h does not have correct behaviour in it. Is the 
>DEC 'C' compiler in error (my K&R 2nd Ed does refer to errno as an integer, 
>but that's all), or am I not allowed to do this?

It's all your fault.  Here's the relevant part of the standard:

    4.1.3 Errors <errno.h>

    The header <errno.h> defines several macros, all relating to the
    reporting of error conditions.

       The macros are 
           ^^^^^^
	     EDOM
	     ERANGE

    which expand to distinct nonzero integral constant expressions; and 

	     errno

    which expands to a modifiable lvalue that has type int...
          ^^^^^^^

(*cma$tis_errno_get_addr()) looks like a modifiable lvalue, so the 
implementation is correct (the cma$tis_errno_get_addr symbol is
definitely not in the user's namespace).

Time to fix your code.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

In <3vo921$n4a@pheidippides.axion.bt.co.uk> thomasgd@boat.bt.com (Greg Thomas) writes:
>however, hit a problem with the <errno.h> include file. It #defines it to be 
>(*cma$tis_errno_get_addr()). The trouble is, we have number of structures that 
the compiler is allowed to do this, ANSI 4.1.3.

>I feel that the DEC 'C' errno.h does not have correct behaviour in it. Is the 
>DEC 'C' compiler in error (my K&R 2nd Ed does refer to errno as an integer, 
>but that's all), or am I not allowed to do this?
you'll hardly ever find ANSI C problems with the DEC C compiler, if
it complains chances are excellent your code is at fault.

   Dan
-- 
--------------------- message is author's opinion only --------------------
J. Daniel Smith <dan@bristol.com>               http://www.bristol.com/~dan
Bristol Technology Inc.	                    +1 203 438 6969, 438-5013 (FAX)
Ridgefield, Connecticut (USA)                       {info,jobs}@bristol.com

thomasgd@boat.bt.com (Greg Thomas) writes: I'm trying to porting some
>code to Alpha/DEC 'C' from VAX/VAX 'C'. We have, however, hit a
>problem with the <errno.h> include file. It #defines it to be
>(*cma$tis_errno_get_addr()). The trouble is, we have number of
>structures that have an errno as an element. Of course, this gets
>expanded to the above function, and so it won't compile. ie ...

The problem is because ISO does not allow "$" in identifiers, but _some_
compilers do in order to access system-defined identifiers with "$" in
them---VAX VMS is notably one that has a few (do I remember SMG$ cor-
rectly?). Just a guess, but are you including the correct headers for
your _current_ compiler?

Best regards,
Derick.
--
+-----------------------------------------------------------------------------+
| Derick R. Qua-Gonzalez                                           | ________ |
| Department of High Energy Physics, California State University   | \      / |
| dqua@EarthLink.Net                                               |  \    /  |
|        ``It is better to be hated for what one is,               |   \  /   |
|          than loved for what one is not.'' (A. Gide)             | G  \/ USA|
+------------------------------------------------------------------+----------+
| mQBNAy/qJJMAAAECANBCB543eTUkdG8Mqx6K2cm3WxCVtKY8ZbB9WY6A2Ne4dQi8 | PGP2.6.2 |
| xh7OxjHXP/eXp5BSbmVAihEGd7r+5g/yknko56kABRG0MERKUiBRdWEtR29uemFs |  Public  |
| ZXogPGRxdWFAUHJvbWV0aGV1cy5FYXJ0aGxpbmsuTmV0Pg==                 | KeyBlock |
| =70DW                                                            | 06.20.95 |
+------------------------------------------------------------------+----------+

In article <3vo921$n4a@pheidippides.axion.bt.co.uk> thomasgd@boat.bt.com (Greg Thomas) writes:

>I'm trying to porting some code to Alpha/DEC 'C' from VAX/VAX 'C'. We have, 
>however, hit a problem with the <errno.h> include file. It #defines it to be 
>(*cma$tis_errno_get_addr()). The trouble is, we have number of structures that 
>have an errno as an element. Of course, this gets expanded to the above 
>function, and so it won't compile. ie ...

[snip]

>Now whilst I can change all our code to not refer to errno in this structure, 
>I feel that the DEC 'C' errno.h does not have correct behaviour in it. Is the 
>DEC 'C' compiler in error (my K&R 2nd Ed does refer to errno as an integer, 
>but that's all), or am I not allowed to do this?

DEC are allowed to do this. Paraphrasing the standard ("Reserved Identifiers" 
and "Errors <errno.h>")

  -   when <errno.h> is included, the identifier 'errno' is a reserved
      identifier.

  -   errno may be a macro; regardless it must result in a modifiable
      lvalue of type 'int'

They even give an example in a footnote not unlike DEC's implmentation.

Claude.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 vv    vv       David Claude Brown
 ||----||  *    brown@falam.ch
 ||     | /
 /\------/
(oo)
(~~)

In article <danpop.807407394@rscernix>, Dan.Pop@mail.cern.ch (Dan Pop) writes
! It's all your fault.  Here's the relevant part of the standard:
! 
!     4.1.3 Errors <errno.h>
! 
!     The header <errno.h> defines several macros, all relating to the
!     reporting of error conditions.
! 
!        The macros are 
!            ^^^^^^
! 	     EDOM
! 	     ERANGE
! 
!     which expand to distinct nonzero integral constant expressions; and 
! 
! 	     errno
! 
!     which expands to a modifiable lvalue that has type int...
!           ^^^^^^^

The standard looks wrong to me ....
full of traps for the innocent.

In <3vqrg1$bem@caip.rutgers.edu> halasz@caip.rutgers.edu writes:

>In article <danpop.807407394@rscernix>, Dan.Pop@mail.cern.ch (Dan Pop) writes
>! It's all your fault.  Here's the relevant part of the standard:
>! 
>!     4.1.3 Errors <errno.h>
>! 
>!     The header <errno.h> defines several macros, all relating to the
>!     reporting of error conditions.
>! 
>!        The macros are 
>!            ^^^^^^
>! 	     EDOM
>! 	     ERANGE
>! 
>!     which expand to distinct nonzero integral constant expressions; and 
>! 
>! 	     errno
>! 
>!     which expands to a modifiable lvalue that has type int...
>!           ^^^^^^^
>
>The standard looks wrong to me ....
>full of traps for the innocent.

The standard is, by definition, right :-)
C is not for the innocent :-)

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@mail.cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

In article <3vqrg1$bem@caip.rutgers.edu> halasz@caip.rutgers.edu writes:
>In article <danpop.807407394@rscernix>, Dan.Pop@mail.cern.ch (Dan Pop) writes
>! It's all your fault.  Here's the relevant part of the standard:
>! 
>!     4.1.3 Errors <errno.h>
>! 
>!     The header <errno.h> defines several macros, all relating to the
>!     reporting of error conditions.
>! 
>!        The macros are 
>!            ^^^^^^
>!            EDOM
>!            ERANGE
>! 
>!     which expand to distinct nonzero integral constant expressions; and 
>! 
>!            errno
>! 
>!     which expands to a modifiable lvalue that has type int...
>!           ^^^^^^^

>The standard looks wrong to me ....
>full of traps for the innocent.

The innocent would not use identifiers defined by the standard for their own 
purposes even if the standard allowed them too.

Name space management is _extremely_ important (IMHO) and is one of VMS's 
strengths. Perhaps the people who wrote the original 'errno' member had 
been lulled by VMS into thinking that they could do no wrong (no $ => OK)

I suggest a global subsititute of '.errno' and '->errno' to a new name as a 
first pass.  These two strings won't show up very often (if at all) in your 
programs other than in the places that you want to change them.

Claude.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 vv    vv       David Claude Brown
 ||----||  *    brown@falam.ch
 ||     | /
 /\------/
(oo)
(~~)