HDTenEightyP/NetNews huggingface dataset:
From: roberts@g2syd.genasys.com.au (Robert Swan)
Subject: offsetof in case labels
Organization: Genasys II, Sydney, Australia
Date: Thu, 21 Jan 1993 23:23:37 GMT

I posted a related question a week or two ago.  ~no response, so I'll
try a different tack.

We have a problem on various machines using the offsetof macro from
stddef.h in case labels.  These machines all reject the expression as
being non-constant.

A representative of one of the machine vendors (IBM), has glibly stated
that the compiler is doing the right thing by rejecting it.  He has
quoted the ANSI standard arguing (in fairly obscure terms) that the
compiler is free to treat various pointer expressions as non constant.

I consider this to be irrelevant, since (as I understand it) the
offsetof macro returns, by definition, a constant expression - exactly
what a case label needs.  The fact that it is usually (always)
implemented as a pointer expression is an implementation detail.

However, I'm pretty much at sea with the ANSI standard - we don't have a
copy, and the excerpts I have seen of it suggest that it is written in
sufficiently obscure legalese to cloud the superficial interpretation I
might put on it.  Could someone who has invested the considerable
effort to understand the standard please clear this up for me.

Should offsetof be usable in case labels?

Have fun,

Robert.
-- 
I used to be indecisive,   | Robert Swan, roberts@g2syd.genasys.com.au
but now I'm not so sure.   | Genasys II Pty. Ltd., North Sydney.
From: gegu@zurich.spectrospin.ch (Gerry Gucher)
Newsgroups: comp.lang.c
Subject: Re: HALLOC and HUGE ptrs in Microsoft C
Summary: C is portable, implementations are not
Date: 24 Jan 93 17:21:30 GMT
Distribution: world,local
Organization: Spectrospin AG, Fallanden Switzerland

In article <1993Jan21.175608.4279@arizona.edu>, jjr@ace.ece.arizona.edu (Jeffrey J. Rodriguez) writes:
> On a 486 running DOS, I need to allocate an array that's bigger than 64K,
> ll it up with data, and write it to a binary file.
> The MSC 7.0 manual says to use halloc(), which returns a "huge ptr".
> It also says that huge ptrs cannot be passed as args to library functions.
> Therefore, I can't pass the array to fwrite()!

I doubt that you interpret the manual correctly.
Huge pointers are simply far pointers that have their seg:offset
pair normalized so that the offset is always smaller than 16.
If a library gets 0x1000:0x0005 it can not tell the difference from a far
pointer. 

> So, how do I write the data? (Do I really have to loop through putchar?)

If anything I would loop over fwrite() to print large binary data.

> 
> This sure seems cumbersome.
> It also seems that a program written for PC-DOS using halloc and huge
> ptrs would not run on a Sun running UNIX.

That is right, but it's easy to fix. Just do:

#define huge	/* empty */
#define halloc(x)      malloc(x)

> So much for portable C.

C is in fact portable. But due to the braindamaged memory architecture,
most if not all compiler vendors in the MESS-DOS world chose to implement
a language that looks like C but isn't C. They invented new
keywords like "huge, far, ..." etc. which makes their language non standard
conformant. When they claim ANSI compatibility, they mean the "small" memory
model only. Fortunately most problems can be solved by defining the problem
away. Additionally every C implementor can extend the library with more
functions (e.g. halloc) and using those makes your code non portable. This
is your problem and has nothing to do with the portability of C.

Back to your question about fwrite(). You can eiter break you fwrite() call
into a series of fwrites() each writing less than 64 kB at once or you can try
to make the size of your items larger (say 1k words) and write less items.
I have never tried this but it might work (even on a PC). Of course you
must use the "large" memory model library for fwrite(). E.g.

  instead :  fwrite( buf, 200000, sizeof(int), fp );
  try     :  fwrite( buf, 2000, 1000*sizeof(int), fp );

I have not tried it but it might work.
> 
> Jeff Rodriguez
> rodriguez@ece.arizona.edu

Gerry


Newsgroups: comp.lang.c
From: wirzeniu@klaava.Helsinki.FI (Lars Wirzenius)
Subject: Re: initialized extern variables, coded in 1 file, used in many
Organization: University of Helsinki
Date: Thu, 28 Jan 1993 17:57:55 GMT

hartman@ulogic.UUCP (Richard M. Hartman) writes:

[ define EXTERN as extern by default, as nothing in main.c ]

>	EXTERN int uninitialized;
>
>	#ifdef EXTERN
>	extern int initialized1;
>	#else
>	int initialized1 = 50;
>	#endif

Wouldn't it be better to do

	EXTERN int uninitialized;
	extern int initialized1;

	#ifdef MAIN
	int initialized1 = 50;
	#endif

instead, since this catches any errors that may creep in when you
forget to change one copy of the initialized1
declarations/definitions?

Of course, one might even go further and move the initializations out
of the header altoghether, since they do no particular good there.  If
they are in the header, and you change an initialization, make will
recompile everything even if it isn't really needed.

If you do that, you can even forget about the EXTERN macro and use
extern throughout, although then you have to add definitions for the
uninitialized variables as well.

In case you didn't guess, this is the style I use.  In summary:

header.h:

	extern int foo;

main.c (or some other suitable source file):

	#include "header.h"

	int foo;

Easy, simple, fairly difficult to do mistakes, doesn't require
preprocessor trickeries.

--
Lars.Wirzenius@helsinki.fi  (finger wirzeniu@klaava.helsinki.fi)
   MS-DOS, you can't live with it, you can live without it.
From: jm59@prism.gatech.EDU (MILLS,JOHN M.)
Newsgroups: comp.lang.c
Subject: Re: Learning c++
Date: 21 Jan 93 14:31:44 GMT
Organization: Georgia Institute of Technology

In article <00966E60.98255E60@Msu.oscs.montana.edu> gjb7307@Msu.oscs.montana.edu writes:
>In article <1993Jan19.233110.2873@ringer.cs.utsa.edu>, pnarsipu@ringer.cs.utsa.edu (Praasad Y. Narsipur) writes:
  [deletions]
>>difference between Borland C++ and Turbo C++. I'm confused by this.
>
> _Currently_, Borland C++ is the DOS environment, whereas Turbo C++ is
> the Windows environment.

That wasn't true last time I looked: there was Turbo C++ for DOS.

There are surely more fundamental differences between the products, but my
subjective sense was that Turbo C++ is a more integrated, but more
limited IDE, where linkage to semi-independent utilities (GREP, TD, etc.)
was not so transparent as Borland C++. BC++ was more picky with warnings 
(which I appreciate), and less tolerant -- I had a published program (Faison's
GUI book's disk) which compiled under TC++, and failed to link under BC++
due to a static variable which was defined but never declared.  TC++
accepted this error and implicitly declared the variable; BC++ refused.  I thus
feel better protected with BC++. I like BC++'s transfer to more functional,
stand-alone utilities: TD, for example, will step backwards or forwards
through a linked list of structures, but the IDE debug function wouldn't do
this.  GREP has saved my patience many times by picking over all files in
a project, allowing me to drop into the editor looking at the (possibly) 
offending line of code, then stepping from file to file to consider and/or
fix the references.

Price differential would stop me for a "home project" tool, though.

I use BC++ v.2.0 and I don't remember the TC++ version -- it was contemporary
with the BC++ release.  These differences may have changed.

Regards --jmm--

-- 
John M. Mills, SRE; Georgia Tech/GTRI/TSDL, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59
Internet: john.mills@gtri.gatech.edu
C++: "Increment C, then return the old value"  - anon
Newsgroups: comp.lang.c
From: pdh@netcom.com (Phil Howard )
Subject: Re: How do you read binary data piped into stdin?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Thu, 28 Jan 1993 11:06:51 GMT

roy%cybrspc@cs.umn.edu (roy) writes:

>pdh@netcom.com (Phil Howard ) writes:
>
>> Unfortunately, standard C lacks a facility to change the mode of an open
>> file.  This would be what you need, and I have had situations where I need
>> this as well.
>
>What about setmode()?  My FM says the call is available on Unix systems.
>Is the FM lying to me?  (I s'pose it wouldn't be the first time)

Your machine may have setmode().  In fact many machines might; I don't know
for sure.  But ANSI C does not, so it is not as portable as C.  Of course
people could use it where it exists and avodi having to do other things.
-- 
/************************************************************************\
| Phil Howard,  pdh@netcom.com,  KA9WGN    Spell protection?  "1(911)A1" |
| "It's not broken... it's just functionally challenged" --Phil and Pete |
\************************************************************************/
Newsgroups: comp.lang.c
From: kimball@stsci.edu (Timothy Kimball)
Subject: Re: The Coming Crisis
Organization: Space Telescope Science Institute
X-Newsreader: TIN [version 1.1 PL6]
Date: Thu, 28 Jan 1993 13:43:02 GMT

George Mitchell (george@tessi.com) wrote:
: 
: In less than 8007 years, asctime () will need a 28-character buffer,
: instead of a 27-character one, in which to return its result.
: -- George Mitchell (george@tessi.com)

My God!  Quick! Somebody convene a committee!  (X3J10000, maybe?)

Bartender!  Smileys all around!

--

/* tdk -- Opinions are mine, not my employer's. */
From: wallace@cs.widener.edu (Dennis Wallace)
Newsgroups: comp.lang.c
Subject: Re: Tlink under os/2
Keywords: Tlink under os/2
Date: 26 Jan 93 15:56:34 GMT
Organization: Widener University CS Department, Chester PA
NNTP-Posting-Host: lucy.cs.widener.edu

>Hi, I run a tlink(ver5.2) under os/2 dos box, it always give a error 
>message, say there is not enough memory. However, there is 2 MB DPMI in the 
>box stting. I also enable the DPMI_DOS_API.
>
>The bc abd the link under the IDE runs fine.
>
>Any idea?

This should depend on the amount of physical memory on your machine,
and how much disk space you have. You shoutld have at LEAST 4 Meg of
ram and about 5 Meg free on the hard drive for swap space.

	DW
Newsgroups: comp.lang.c,comp.lang.c++,comp.os.msdos.programmer,comp.sys.ibm.pc.programmer,relcom.fido.su.c-c++,relcom.msdos
From:  paul@soft.ntc.togliatti.su (Paul A. Karasev)
Subject: Bug in Borland C/C++ v3.0 code generator
Keywords: bug bcc C C++ _fastcall
Reply-To: paul@soft.ntc.togliatti.su
Organization: Solar Trading
Date: Mon, 25 Jan 1993 14:39:04 GMT


Hi!

I've found a bug in BC 3.0 code generator - I haven't the List of known 
bugs nether for BC nor for MS so  ... :-(((

To understand the bug just look at following source and compare with 
code produced by BCC. (my poor englishhhh don't allow me to write 
all I want)


source of fast_bug.c: 
--------------------------------- CUT HERE ------------------------------------

typedef	int	(_fastcall *procPtr)(int*, int*);

int	_fastcall	proc1(int*,int*);
int	_fastcall	proc2(int*,int*);

procPtr		decodeArray[] = { proc1, proc2 };

int	execute(int code)
{
	int	arg1, arg2;

	return decodeArray[code]( &arg1,&arg2 );	// !!!! Bug here !!!!
}

int	_fastcall	proc1(int* a, int* b)
{
	return *a = *b ;      // Just to prevent warning
}

********************************************************************************
The *wrong* code produced by BCC v3.0 (-c -S -O2)
-------------------------------------------------

	.
	. Skipped
	.
_execute	proc	near
	push	bp
	mov	bp,sp
	sub	sp,4
   ;
   ;	{
   ;		int	arg1, arg2;
   ;
   ;		return decodeArray[code]( &arg1, &arg2 ); // !!!! Bug here !!!!
   ;
	lea	ax,word ptr [bp-4]      ; Load arg2 - OK
	lea	bx,word ptr [bp-2]      ; Load arg1 
	mov	bx,word ptr [bp+4]      ; !!! BUG Overwrite arg2 with addr. of array !!!
	shl	bx,1
	call	word ptr DGROUP:_decodeArray[bx]
   ;
   ;	}
   ;
	mov	sp,bp
	pop	bp
	ret
_execute	endp
   ;
   ;	int	_fastcall	proc1(int* a, int* b)
   ;
	assume	cs:_TEXT
_proc1	proc	near
	push	bp
	mov	bp,sp
	sub	sp,2
	push	si
	mov	word ptr [bp-2],ax
   ;
   ;	{
   ;		return *a = *b ;      // Just to prevent warning
   ;
	mov	si,word ptr [bp-2]
	mov	dx,word ptr [si]
	mov	word ptr [bx],dx
	mov	ax,dx
   ;
   ;	}
   ;
  .
  . Skipped
  .

********************************************************************************
Here *correct* code of same source compiled with MS C v 6.0 (/Oxaz /Gr /c /Fa)
(Just to compare)
-------------------------------------------------------------------------------
  .
  . Skipped
  .

;	register ax = code
;	arg1 = -2
;	arg2 = -4
	mov	si,ax
; Line 14
	shl	si,1
	mov	ax,WORD PTR _decodeArray[si]
	mov	WORD PTR [bp-6],ax
	lea	bx,WORD PTR [bp-2]	;code // ?? it's arg1 (wrong comment)
	lea	ax,WORD PTR [bp-4]	;arg2 // arg2
	call	WORD PTR [bp-6]
  .
  . Skipped
  .

********************************************************************************

Can somebody send me list of known bugs in DOS C/C++ compilers ?
(If you have the list and decide to send it, ask me before you 
do it, please).

Yours,

paul@soft


paul@soft


Newsgroups: comp.lang.c,comp.os.msdos.programmer
From: jochenr@neuro.informatik.uni-kassel.de (Jochen Ruhland)
Subject: Re: Reading the arrow keys... how?
Organization: FG Neuronale Netzwerke - Uni Kassel
Date: Thu, 21 Jan 1993 17:24:51 GMT

In article <1jmeupINN4g9@savoy.cc.williams.edu>, 93gke@williams.edu (Just Ask The Axis) writes:
|> I am trying to read the arrow keys from a PC keyboard in C. So far
|> the calls to getch(), getc(), getchar(), have been unsuccessful
|> because the keys don't seem to have a corresponding ASCII code (they
|> seem to send 2 characters..?) I also need to read some regular keys
|> like Q,S, etc... 
|> Could someone tell me how to read them directly, please.
|> 
|> Greg Ennis
|> 93gke@cs.williams.edu
|> 
The "special" keys on a PC - Keyboard indeed consist of two chars, the
first one beeing a chr(0), the second depending on the key.

You could also use direct BIOS-calls to the keyboard. Try looking if
your compiler supports a conio.h include-file. You should find all
necessary functions there.
-- 
*     FG Neuronale Netzwerke / Uni Kassel       * 
*     Jochen Ruhland                            *
*     Heinrich-Plett-Str. 40                    *
*     D-3500 Kassel                             *
*     jochenr@neuro.informatik.uni-kassel.de    *
Newsgroups: comp.lang.c
From: traal@lopez.marquette.MI.US (Brian Phillips)
Subject: MIX Software on the Internet?
Organization: Great White North/UPLink
Date: Mon, 25 Jan 1993 06:01:11 GMT


Does anyone out there know if MIX Software is on the Internet or in any way
can be reached via EMAIL?
MIX Software is best known for (I think) their Power C compiler & debugger,
and now for Multi-C (a portable, multi-threaded extension to C).
If anyone has any information, please respond by EMAIL, as I'm not sure if
my site gets all these groups.

  --Traal the BRAVE 
-- 
  EMAIL (the Good, the Bad, or the Flame) to:  traal@lopez.marquette.MI.US
   "Take a walk through the looking-glass and see the other side!" -- BPP
            "Realism is often misconstrued as pessimism." -- BPP
          "My mailer hates everybody, be sneaky." -- Mary Margret
Newsgroups: comp.lang.c
From: rfries@sceng.ub.com (Robert Fries)
Subject: Re: Problem with BC 3.1 vs. Gnu C
Organization: Ungermann Bass
Date: Tue, 26 Jan 1993 16:22:10 GMT

In article <1k3n0vINNg09@boa.cis.ohio-state.edu> imes@cis.ohio-state.edu (jeffrey imes) writes:


>Here's the situation:
>The program is very simple.  It just reads in decimal (integer) numbers from 1
>to max size of type (using unsigned int in UNIX, unsigned long in DOS...should
>produce same range) and converts them to a string of "hexadecimal" characters
>(I quote that since they're not actual hex, just actual ASCII characters
>re would look like in hex) look like in hex).  When run under UNIX, it will
>successfully read in any number from 1 to 2,147,483,647 and convert it to hex.
>When run under DOS, at every multiple of 2^16 (65536) I think overflow occurs
>and it resets the number back to zero.  So 1=1, 10=A, 16=10,...,65535=7FFF,
>and then 65536 won't work.  Then, 65537=1,65538=2,...

>Here's the code:

>.
>.
>.                 or long for BC
>main()            |
>{                 V
>       unsigned int    dec_num,temp,.....;
>       char    hex_num[10],hex,....;

>       printf("input a number 1-->2^32-1: ");
>       scanf("%d",&dec_num);
>       if ((dec_num < 1) || (dec_num > 2147483647))
>               printf("Invalid range..try again...");
>       if...
>.
>.
>.

>and on and on.  Now, shouldn't the first scanf see that 65536 is a legal
>number and let it go?  Then later on, why would it reset numbers greater than
>65536 to 0?

I think this is caused by using %d in your call to scanf. Using BC3.1
this will get a 16 bit number. I'm pretty sure you need to use something like
%ld to get a long.

Robert


//////////////////////////////////////////////////////////////////////////
Robert Fries
Ungermann-Bass Inc.

DISCLAIMER:
    Opinions contained herein are my own, and are not necessarily those
    of Ungermann-Bass.
//////////////////////////////////////////////////////////////////////////
From: wallace@cs.widener.edu (Dennis Wallace)
Newsgroups: comp.lang.c
Subject: Re: Could someone answer my question....thanks
Date: 26 Jan 93 15:52:37 GMT
Organization: Widener University CS Department, Chester PA
NNTP-Posting-Host: lucy.cs.widener.edu


>Following is a C program in which I tried to simulate command
>line arguments (argc, argv). I am not getting the expected
>output which should be the same as when argc, argv are used.
>
>
>
>#include <stdio.h>
>
>main(arg1,arg2)
>int arg1;
>char *arg2[];
>{
>       int i;
>       for(i=0;i<arg1;i++)
>               puts("%d - %s",i,arg2[i]);
>}
>
>
>The following is the output when I tested the program for diff no.
>of arguments. The 'for' loop iterates exactly the number of arguments,
>but when I tried to print the number of args, as u can see from the
>output, I am getting it wrong...
>
>6:45pm C-> a.out arg2
>%d - %s
>%d - %s
>6:45pm C-> a.out arg2 arg3
>%d - %s
>%d - %s
>%d - %s
>6:46pm C-> a.out arg2 arg3 arg4
>%d - %s
>%d - %s
>%d - %s
>%d - %s
>6:46pm C-> a.out 
>%d - %s
>
>
>Could somebody suggest me in this regard ? Thanks in advance.
>
>Sekhar Chitti
>
:
:Well, as far as I know, puts() does not recognize any format
:specifiers (like %d, %s, etc).  It just takes a string as an argument
:and prints it out on the sdout.  That's why you get these results (it
:prints just the string, i.e. whatever is inside the quotation marks).
:

One other thing. There is ALWAYS an extra argumentwhen you read in the
command line. The argument *arg2[0] is almost always the name of the
program. 
	DW
Date: Sunday, 24 January 1993 01:15:24 EST
X-Mailer: TMail version 1.14R
From: "Tim Triemstra" <empath@ais.org>
Organization: Empath Software
Subject: Re: C and assembly linking problems ! HELP!!
Newsgroups: comp.lang.c
Distribution: world

In <C1BJ1I.8zv@cs.mcgill.ca>, james@cs.mcgill.ca (Luc MIKISZKO)  wrote:
   >		I do exactly this:   tcc l1.c
   >				     tasm l2
   >
   >		Then, no problem, not a single warning or error;
   >
   >		BUT when I link them : tlink l1 l2, exefile
   >
   >		Then I get messages saying that functions such
   >		as "GETCH_", "PRINTF_" are not defined ?!?!?!?
 
 This is probably because you are used to compiling and linking from the
 same command line.  In most compilers (including TurboC etc) you must
 explicitly list the libraries you wish to link when just "tlink"ing or
 using a linker stand-alone from the batch compile command line.
 
 I'm not sure of the filename, but there should be a file in the .lib 
 directory that is pretty big (with a .lib extention) that ends in
 l, s, m or something with respect to a memory model.  An example for large
 memory model would be cl.lib or cm.lib for medium.  Just looking in the 
 lib directory should make it obvious which one to link.  Of course, this
 should be the same with respect to the model you use by default.  I noticed
 you didn't have a -m? switch so you must have the -m switch defined in a
 turboc.cfg file or something like that.
 
 If your environment variables (like SET LIB=C:\TC\LIB) are set right,
 you should just be able to add cl.lib or whatever to the list of answers
 you must respond with to tlink.
 
 Hope this helps.  BTW:  You should probably read up on the command line
 usages.  I personally (as do many programmers) prefer command line usage
 cause you can write your own batch/make files and use your own word 
 processor or editor.  Not to mention less memory....
 
 Good luck.
 Tim.
 

-------------------------------------------------------
| When the end comes, there will be two men standing: |
|   Me, and the guy I gotta kill.   - Gosh I'm EVIL   |
------ Tim Triemstra ------------- empath@ais.org -----
From: kdq@quest.UUCP (Kevin D. Quitt)
Newsgroups: comp.lang.c
Subject: Re: Unwanted float to double conversion in variable length arg lists
Date: Mon, 25 Jan 93 16:36:13 PST
Reply-To: srhqla!quest!kdq
Organization: Job quest  (805) 251-8210,  So Cal: (800) 400-8210

dmarer@td2cad.intel.com (Dennis Marer) writes:

> I've got a curious problem when passing floats in a variable length argument
> list...they are automatically converted to doubles, EVEN when I typecast.
> Consider:
> 
> #include <stdarg.h>
> 
> void func(int num,...) {
...
> }
> 
> int main() {
> func(4,1.0,1.0,2.0,2.0,3.0,3.0,4.0,4.0);
> func(2,(float)1.0,(float)1.0,(float)2.0,(float)2.0);
> }
> 
> I have explicitly typecast a real number to (float), and it still ends 
> up on the stack as a double!

    Yep.  Casting something as float does not prevent the automatic
promotion to double when no function prototype is in scope.  Since
your function func does not specify floats, C *must* convert to
doubles.  Make sense?

ffunc( float foo )
{
...
}
main()
 float f = 3.14;

 ffunc( (int)f )
}
    What should the compiler do?  Completely ignore the typecast or
convert f to an int (should get a warning about possible loss of
precision), and then back to a float as the function prototype
requires? 


 _
Kevin D. Quitt      96.37% of all statistics are made up.     srhqla!quest!kdq
Newsgroups: comp.lang.c
From: darcy@druid.uucp (D'Arcy J.M. Cain)
Subject: Re: HALLOC and HUGE ptrs in Microsoft C
Date: Wed, 27 Jan 1993 23:29:21 GMT
Distribution: world,local
Organization: D'Arcy Cain Consulting

raskin@ccu.umanitoba.ca (Alan Raskin) writes:
>Actually, I think that fwrite is one of the library routines that *will*
>take huge pointers; according to an old QuickC manual, "a huge array can
>be passed without difficulty to any of these [bsearch, fread, fwrite, halloc,
>hfree, lfind, lsearch, mem* and qsort] functions in a compact-, large-, or
>huge-model program."                                  ^^^^^^^   ^^^^^
 ^^^^

That's the problem - it isn't consistent across all models.

>Because of the <expletive deleted> segmented-memory architecture of the Intel 
>80x86 CPUs, which at times requires the use of the non-portable "near", "far" 
>and "huge" keywords, the only way to write "portable" C would be to use 
>#if defined ( MSDOS )  /* M_I86 is also defined by MSC; what about Borland? */
__MSDOS__ is defined by Borland and I believe by MSC as well.

>.
>.	halloc(...);
>.
>#else
>.
>.	malloc(...);
>.
>#endif

While I agree with you about segments (*) in this case why not just:

#ifdef __MSDOS__
#define halloc malloc
#endif

Just once at the top.

(*) Q: What's the difference between an IBM PC and a boat anchor?
    A: Segment registers.

-- 
D'Arcy J.M. Cain (darcy@druid.com)  |
D'Arcy Cain Consulting              |   There's no government
Toronto, Ontario, Canada            |   like no government!
+1 416 424 2871          DoD#0082   |