HDTenEightyP/NetNews huggingface dataset:
From: guenther@stolaf.edu (Philip Guenther)
Newsgroups: comp.lang.c
Subject: Re: const and pointers in ANSI C
Date: 12 Jan 93 21:02:27 GMT
Article-I.D.: snookles.GUENTHER.93Jan12150207
Organization: Academic Computing Center, St. Olaf College

In article <1993Jan12.164949.15684@clsi.COM> shankha@clsi.COM (Shankha Mitra) writes:
   Consider the following C code:
	   int * const constant_pointer;
	   const int *pointer_to_constant_data;
   So the location of the type qualifier const in the declaration
   determines whether the pointer itself or the contents is the
   constant entity. 

   Now suppose you use this instead:

	   typedef int *int_pointer;
	   const int_pointer x;
	   int_pointer const y;

   My compiler (xlc on the RS/6000) which is fully ANSI compatible (or
   so they claim) considers the declarations of x and y to be
   equivalent; it considers x and y to be constant pointers.  That is
   I can say, 

	   *x = *y = 1;

   but not

	   x = y = &i;

   Interesting, huh?

How about the differences between the following:
	const int i;
	int const i;
There are none!  Your problem is that you see a typedef as a pretty
macro. It isn't.  When you say 'typedef int *int_pointer', you have
created a new type.  (As a gross over simplification) when you declare
a variable of a given type, you reserve a memory area big enough to
hold that type *without interpreting what the type 'means'*.  Thus the
fact that you declared y to be "const int_pointer" says that y must be
large enough to hold an "int_pointer" (whatever that is!) and that it
can't be modified.

   My questions: 
	   1) Why this disparity in behavior between using explicit
	      types (the first code fragment) and typedefed types
	     (second code fragment)? 

In the one, the const is either part of the type or a type modifier
while in the other (the typedef case), the const is only a type
modifier.

	   2) Is it possible to make a declaration of a pointer to
	      constant data using the typdefed int_pointer?  If so, how?

No.  This would require the compiler to take apart the typedefed type
to determine how to apply the const.  This isn't hard, but it isn't
desireable.  You can already do it with macros and it would break the
concept of the typedef.  Consider what would happen if you later had
to change int_pointer to be a struct or a pointer to a pointer, or...

   Shankha

Philip Guenther
--
guenther@stolaf.edu (Philip Guenther)       | The ACC might agree with me,
Student Sys Prog, Academic Computing Center | but with that bunch, (and me)
St Olaf College, Northfield, MN 55057       | you never know... :-| :-( :-)
"Life makes sense?  LIFE MAKES SENSE!?!?  Where do people get these ideas?"
From: ychen@csd4.csd.uwm.edu (Yin Chen)
Newsgroups: comp.lang.c
Subject: C/C++ database book
Date: 8 Jan 1993 19:38:24 GMT
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Distribution: usa
NNTP-Posting-Host: 129.89.7.4
Originator: ychen@csd4.csd.uwm.edu



I'm looking for a good book on database programming using
C or C++, any recommendations would be appreciated.
I'd also like to hear opinions on Al Stevens' "C Database
Development".

Thanks.

Chen
Newsgroups: comp.lang.c
From: rince@dcs.warwick.ac.uk (James Bonfield)
Subject: Re: sccs eats good code -
Organization: Department of Computer Science, Warwick University, England
Date: Mon, 4 Jan 1993 11:34:18 GMT

In <1992Dec26.062743.7520@robohack.UUCP> woods@robohack.UUCP (Greg A. Woods) writes:

>> Do you notice anything blindingly wrong with this? Sccs has the intelligent
>> idea of giving control characters special meaning within the history file.
>> And it doesn't bother to escape any of the ones you happen to have typed in.
>> This,naturally, means that if you enter a control char into your source then
>> upon the next 'get' or 'edit' sccs will kindly remove the only existing copy
>> you've got and *then* complain that it doesn't understand the history file.
>> For this reason using sccs actually slowed down and hampered my development
>> by a huge factor. Surely this isn't the scheme of such things? On the
>> contrary the next time I was asked to make use of such a system I put RCS
>> to the test

> 
> Whew!  What kind of code were you writing anyway?!?!?  I've only twice
> encountered a conflict with SCCS's keyword expansion control codes --
> once in the same situation as the original poster noted, and once when
> I wished to include an example SCCS keyword string in a source module.
> 
> That's twice out of thousands of modules.  I know of large projects
> with millions of lines of code, in tens of thousands of modules, all
> managed with the use of SCCS, and no conflicts that couldn't be easily
> dealt with.
> 
> RCS will do the same thing, though it has far fewer combinations of
> strings with which it might find conflict.

The insertion of a control character (^A I believe) was infact accidental. The
point I'm making is that sccs didn't just replace it with something else (as
in the previous complains of %whatevers), but actually mangled the history
file and deleted the only correct copy of the source code.

This bug does not exist is RCS. RCS makes use of the @ symbol in it's history
file. If you insert an @ into your source then all RCS does is to escape this
by using @@ in the history file. This is of course the correct and quite
natural way to do things.

Of course both systems have the expansion of characters to different
characters. This is a feature and not a bug and is quite independant from the
problems I faced.

The next time I decide to use a control system I'll probably investigate CVS
as I've heard so many good (and only good) reports.
-- 
James Bonfield (jkb@mrc-lmba.cam.ac.uk / rince@dcs.warwick.ac.uk)
Medical Research Council Laboratory of Molecular Biology, Hills Road,
Cambridge, CB2 2QH, England. Tel: 0223 402499   Fax: 0223 412282
From: folsom@bigmax.UUCP (Al Folsom)
Newsgroups: comp.lang.c
Subject: Re: Conversion of BASIC code to "C"
Summary: BASTOC
Date: 11 Jan 93 13:35:55 GMT
Organization: Fischer & Porter Co., Warminster, PA.

In article <1993Jan8.183821.20711@adobe.com>,  (Scott Sivi) writes:
> Does there exist a method or application by which BASIC files can be
> converted 
> to "C".


You might try a company called JMI Software, located in Springhouse
PA.  They're telephone is (215) 628-0840.  The sell a product called
BASTOC, which works with a wide variety of Basics.  I have not used
the product, nor do I have any interest in BASTOC or JMI, but a 
friend works there and is the architect of the package.

Al F.

+-------------------------------------------------------------------+
| Al Folsom                 | Object Oriented Programming?  We've   |
| Fischer & Porter Co.      | been doing that for years...          |
| ...uunet!bigmax!folsom    |                                       |
| also folsom@decus.org     | When the customer objects to the way  |
| KY3T@WA3TSW (Ham)         | it works, we go program some more!    |
+-------------------------------------------------------------------+
From: kbw@po.CWRU.Edu (Kevin B. Williams)
Newsgroups: comp.lang.c
Subject: Scrolling Graphics on and IBM compatible
Date: 9 Jan 1993 01:44:10 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: kbw@po.CWRU.Edu (Kevin B. Williams)
NNTP-Posting-Host: slc5.ins.cwru.edu


How do I create scrolling graphics?  I thought about creating an array that
stores a grid of information about a map in 40 pixel blocks.  How do I send
that memory information to the video card.  I know how to do it for text, but
not graphics.

I use Turbo C++ 3.0 on a 486-33 with a Trident 8900C VGA card.

Thanks...

Kevdog
-- 
Name that quote!
"You shall have camels, desert vehicles, an armed escort, and tanks."
"You're welcome."
Newsgroups: comp.lang.c
From: nathan@inmos.co.uk (Nathan Sidwell)
Subject: Re: Is that ansi ?
X-Newsreader: TIN [version 1.1 PL8]
Date: Fri, 8 Jan 93 16:54:50 GMT

J. D. McDonald (mcdonald@aries.scs.uiuc.edu) wrote:
: In article <1993Jan8.142730.20697@osf.org> daniel@moonshine.osf.org (Daniel Dardailler) writes:
: >A compiler is reporting the following warning:
: >  "void * and function pointers are not convertible to each other"
: >when encountering:
: >       void * p = (void *) func ;   /* func of any kind */


: I'm afraid it's true, and one of the most serious faults of ANSI C.

And a very good reason for it too. As I emailed to Daniel, some systems require
more than an instruction pointer to reference a function. For example an
environment pointer. Now ANSI could have said void * is big enough to 
hold any pointer, but then on such systems, most void pointers would carry
extra unrequired baggage with them.

: Function pointers are orthogonal to everything else.  What you can do
: is somehow convert them to an integer type and convert that to 
: void * pointer and then go back. The standard itself does not 
: guarantee that the conversion will get back the right answer however.
: (For those who need a proof, checked with Doug Gwyn, that this can be done:
: enclose the function pointer in a struct, write out the struct to a 
: file using fwrite, then read back in into a char array of the correct size.
: This is guaranteed to work.) Another way is to try and use unions. This
: is not absolutely guaranteed to work.

: Doug McDonald

Another way, which doesn't require file io is, (unchecked, I may
have got the casting slightly wrong).

void (*fptr)(void);
char *cptr;

fptr = (void (*)(void))function;
cptr = (char *)&fptr;

/* cptr now points to an array sizeof(fptr) of chars which are the function
pointer */

Now I'm not 100% sure that you can cast any function pointer to void (*)(void), and
back again without loss, but I can find nothing in ANSI which states this, and
can think of no reason why that might not be so.

nathan
--

Nathan Sidwell  INMOS UK |                 | nathan@inmos.co.uk       DoD#0390

Newsgroups: comp.lang.c
From: geiser@pictel.com (Wayne Geiser)
Subject: Re: Recurring date/times?
Organization: PictureTel Corporation
Date: Tue, 5 Jan 1993 17:57:37 GMT

In article <C0D387.HEH@panix.com>, rmah@panix.com (Robert Mah) writes:
|> Anyone have any suggestions on good data structures for representing 
|> recurring dates and times.  That is, things like "the first teusday
|> of every month" or "three days before the end of every month", etc.
|> 
|> I'm looking for something flexible and compact that I can easily check
|> to see if a given date/time falls on the recurring date/time.
|> 
|> Thanks,
|> Rob
|> 
|> -- 
|> [--------------------------------------------------]
|> [  Robert S. Mah   |  "Every day an adventure,     ]
|> [  rmah@panix.com  |   every moment a challenge."  ]
|> [--------------------------------------------------]

There are actually very few forms that one needs to represent a great variety of
date forms.

weekday on or before date - This gives you things like 2nd Tuesday
date + days
date - days               - This gives you things like 3 days before end
                            of month (i.e., 4 days before 1st of next month,
                            so you don't have to know how many days are in the
                            month)
everyday

I used this type of date logic in a shareware program I wrote called "On This
Day" (look for otd??.zip on simtel, garbo, and other quality servers :-)).  My
dates were expressed in text and look something like:

m	Monthly event (Gregorian number)
m/d	Gregorian event with no associated year
m/d/y	Gregorian event
Hm/d    Jewish event (i.e., Hebrew calendar)
HFm/d   Jewish fast day (special rules apply)
Im/d    Islamic event
Jm/d    Julian event
*       Every day
M(m/d)  Monday on or before date (T, W, R, F, S, U are the other days of the
        week)
E       Easter
m/d+days Add number of days to the date
m/d-days Subtract number of days from date

There are lots of permutations:

E+60    Gives you Corpus Christi (Thursday following Trinity Sunday)
H1/1-16 Gives Purim (needs odd calculation because of leap months in the
        Hebrew calendar
W(*)    Every Wednesday
M(1/31) Australia Day Observed (Monday on or after 1/26).
*+1     Tomorrow

Anyway, you get the idea.  Possibly you can take the same ideas and use them
in designing your data structures.  I've found them to be remarkably flexible.
-- 
**********************************************************************
* Wayne Geiser ("Drivel King")           Voice:    (508) 977-8253    *
* PictureTel Corporation                 FAX:      (508) 532-6893    *
* One Corporation Way                    Internet: geiser@pictel.com *
* Peabody, MA      01960                 CIS:      70313,3615        *
*                                        GEnie:    W.GEISER          *
**********************************************************************
"... I've got to figure out how to make it clearer that we are for the
 things that I have advocated that would help."

        - George Bush.
Newsgroups: comp.lang.c
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: Linker problem
Date: Sat, 9 Jan 1993 02:11:07 GMT
Organization: TH-Darmstadt

In article <1993Jan7.164628.22131@newsgate.sps.mot.com> gupta@adtaz.sps.mot.com (Rajesh Gupta) writes:

>   I am creating a debuggable executable by statically linking in a few
>   archives. However, the linker fails to recognize the symbols in one
>   of the ar libraries ????

You did not tell us your environment.

>   I can't see where the problem could be. Any clues will be appreciated.

1) On BSD-derives including SunOs: try to run "ranlib"

2) On  sysV68R3.[67] as delivered by Motorola:
	-) perhaps one new bug inside the linker. It has problems with
	large symbol tables ;->

>   --- Rajesh
best, adams
From: jm59@prism.gatech.EDU (MILLS,JOHN M.)
Newsgroups: comp.lang.c
Subject: Re: computer.lang.c
Date: 10 Jan 93 22:50:37 GMT
Organization: Georgia Institute of Technology

In article <1993Jan10.162605.503@hpb.hwc.ca> jshaw@hpb.hwc.ca writes:
>trying to learn how to use post command with no instructions
>In case this message works I'll make it complete. I'm new to news.
Welcome aboard.  Put on your Nomex underware, and stick with it!

 >respond directly to jshaw@hpb.hwc.ca thanks
 >post

 >post
 >cancel
 >exit
 >quit
 >cancel

Now, wasn't that fun!  Reminds me of my first Word*Star foray -- finally I
pulled the plug on the @#$%^!! .. maybe it would work for you.

Speaking of that, @#$%^!! is what I usually say to exit my program  (and
re-enter my shell [8*>)

Regards --jmm--

-- 
John M. Mills, SRE; Georgia Tech/GTRI/TSDL, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59
Internet: jm59@prism.gatech.edu
 ... Not so fast -- I'm still thinking.
Newsgroups: comp.lang.c
From: bryan@sphinx.phys.Virginia.EDU (bryan wright)
Subject: Curses question: printf after initscr
Organization: University of Virginia
Date: Sat, 9 Jan 1993 22:38:15 GMT

Hi folks,
	This may be a FAQ, but it doesn't seem to be frequently answered:

Why does the following program wait for a carriage return before sending
the text "hello there" to the screen?  (OS is Ultrix 4.0 on a DS3100.)

#include <stdio.h>
#include <cursesX.h>
main()
{
	char string[BUFSIZ];

	initscr();
	endwin();
	printf ("hello there");
	gets ( string );

}

This comes up because I'd like to write a curses interface for an existing
application.  Ideally, I'd call initscr at startup, then switch between
curses and plain text by using 'refresh' and 'endwin'.  Unfortunately, once
I've called initscr I have to explicitly flush stdout whenever I use printf
thereafter.  I'd hate to have to rewrite all the I/O in terms of curses 
routines.

	Is there something simple I'm missing?  Any advice would be 
appreciated.

				Thanks in advance,
				Bryan
--
===============================================================================
Bryan Wright                |"If you take cranberries and stew them like 
Physics Department          | applesauce, they taste much more like prunes 
University of Virginia      | than rhubarb does."  --  Groucho 
Newsgroups: comp.lang.c
From: lipson@dms.agames.com (Pete Lipson)
Subject: Re: Why would someone put 'char x[]' inside of a struct decl?
Organization: Atari Games Corporation
X-Newsreader: TIN [version 1.1 PL6]
Date: Tue, 5 Jan 1993 17:41:41 GMT

Mike Bandy (bandy@netnews.jhuapl.edu) wrote:
: peter@deepthought.unm.edu (Peter Blemel) writes:
: 
: >I'm trying (really I am) to write a Microsoft Windows app, and I've come across
: >a structure (Prog ref, vol 4 pg90) that looks something like...
: 
: >struct DialogBoxHeader {
: >	char szMenuName[];
: >	char szFaceName[];
: >};
: 
: Look at the struct as:
: 
: struct DialogBoxHeader {
: 	char *szMenuName;
: 	char *szFaceName;

 - an array is NOT a pointer.  Why do you think this is supposed to work?
-- 
  /V\
-/@-*\- Peter Lipson <-- lipson@agames.com   or   netcom!dms!lipson
 \_o_/  Milpitas, CA <-- Atari Games
   U
Newsgroups: comp.lang.c
From: obaid@sdf.lonestar.org (Obaid Alvi)
Subject: Re: adding strings together
Organization: sdf public access Unix, Dallas -- 214-436-3281
Date: Thu, 7 Jan 1993 01:57:21 GMT


Joining strings using the + operator like str1=str2+str3;
Well, C++ is just for this kind of facilities.

unsigned amjad;


Newsgroups: comp.lang.c
From: msb@sq.sq.com (Mark Brader)
Subject: Re: extern: interesting case...
Summary: some basics about pointers and arrays
Keywords: extern
Organization: SoftQuad Inc., Toronto, Canada
Date: Fri, 8 Jan 93 07:36:35 GMT

> char line[80];
> char *linep= line;
> tells the compiler that the object named `linep' is a pointer, pointing
> to an 80 bytes wide piece of memory that can also be refered to as `line'.

Actually, `linep' points to the FIRST of the 80 bytes.  However, because
of the way arrays and pointers work in C, that is exactly what you want
if you intend to access the other bytes as well, one by one.  (See Section
2 of the comp.lang.c FAQ list, and/or any reasonable quality C book.)
In fact, this is so true that people sometimes slip up (or speak loosely)
and *say* that the pointer is pointing to the whole array, as in the
text quoted above.  But it really is not.

The reason it points to a BYTE is that its type is "char *" and a char
is always one byte in C.  (This does not necessarily mean 8 bits; it
could be more.)  If we had

	int thing[80];
	int *thingp = thing;

and if ints are, say, 2 bytes long, then thing is 160 bytes, and thingp
is pointing simultaneously to the first TWO of them.

It is probably better to NOT think of pointers in terms of bytes, but
in terms of objects.  Now thing contains 80 ints, and thingp points to
the first of these ints.  See, now there's no difference between int *
and char *, except the substitution of "int" for "char".  And you don't
need to know the number of bytes in an int to understand the code.
-- 
Mark Brader		"It's important not to let the structure of the
Toronto			code determine the functionality of the program ...
utzoo!sq!msb		The desired functionality should be predetermined
msb@sq.com		before the code writing is done."	-- Dave Sill

This article is in the public domain.
From: dave@cs.arizona.edu (Dave Schaumann)
Newsgroups: comp.lang.c
Subject: Re: C code Layout
Date: 8 Jan 93 00:34:37 GMT
Reply-To: dave@cs.arizona.edu (Dave Schaumann)
Organization: University of Arizona

In article <76210@apple.apple.COM>, apn@Apple (Alex Novickis) writes:
>In article <MITCH.92Dec24105749@pollux.clsi> mitch@clsi.COM (Mitchell N. Perilstein) writes:
>>> P.S I've got some macros for vi that solve mazes. Try that in poo. Sorry,
>>> EMACS.
>>
>>I've got some lisp for emacs which emulates vi.  Does vi emulate emacs?
>>
>That's exactly it!!!!!! Emacs users still have a need for vi ( I guess to
>do real editing) and vi users have no need for emacs ( for whatever it
>is used for )

Oh, brother.  Editor flame wars again...

Personally, I use gnuemacs.  Why?

  -automatic paren matching ( and ), [ and ], { and }
  -automatic indentation (in multiple lanugages, not just C...)
	this also saves syntax errors.  miss a quote or a paren,
	and your indentation goes hay-wire.
  -M-x compile -- run my make file without leaving the editor.  Plus
   it takes me to the exact file and line of the error with a single
   key-stroke.
  -M-x gdb -- running the debugger within the editor is gold.  One window
   shows the source file and what line the execution is on, the other window
   shows the command history.

I seem to remember seeing something that suggested you couldn't use multiple
windows/buffers with vi, either... but I can't imagine that vi would be 
held up as a useful editor without this basic (and incredibly useful)
feature.

It's also got some great toys available for it: M-x disassociated-press,
M-x doctor, M-x eliza, M-x yow, M-x psychoanalyze-pinhead, M-x flame, ...
I also use it to read news (with Gnews, a rn-like but superior news reader).

Now there are points that you can bash gnuemacs on if you like, but lack
of functionality and extensibility is NOT one of them.

PS: I do not use vi, nor do I use gnuemacs' vi emulation.  :-p
Newsgroups: comp.lang.c
From: mccall@mksol.dseg.ti.com (fred j mccall 575-3539)
Subject: Re: Where to include
Organization: Texas Instruments Inc
Date: Tue, 12 Jan 1993 18:52:43 GMT

In <C0ID0z.504@ulowell.ulowell.edu> vpham@cs.ulowell.edu (vinh) writes:



>fun()
>{
>}

>#include <stdio.h>


>fun2()
>{
>	printf("test...");
>}

>we argued at work about where to put stdio.h; obviously fun()
>isn't calling anything declared in <stdio.h>, so  don't think
>stdio.h should be included at the beginning of the file; my
>co-fellow worker thinks it's ugly ; what do you think?
>what does the standard say? what does K&R say?

This is one of those maintenance oriented stylistic issues.  Putting
the '#include' statements anywhere but the top of the file is a
maintenance problem waiting to happen.  The '#include' has file scope,
and so should reasonably occur once at the top of the file.  Doing it
the way you show above almost 'feels' like you want it to have FUNCTION
scope, instead.




-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.
Newsgroups: comp.lang.c
From: tobis@skool.ssec.wisc.edu (Michael Tobis)
Subject: Re: Moving from Pascal to C, Help please!!!!!! 
Organization: U.Wis.-Madison; Atmospheric & Oceanic Sciences
Date: Tue, 12 Jan 1993 21:48:20 GMT

In article <1993Jan12.190826.20740@mksol.dseg.ti.com>, mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
|> In <726510754snz@panache.demon.co.uk> raph@panache.demon.co.uk (Raphael mankin) writes:
|> 
|> >IMHO the only thing one can say about pointer arithmetic is DON'T.
|> 
|> There's singularly bad advice from someone with that much experience.
|> 
|> >If your pointer points to an array, use subscripting. Let the compiler's
|> >optimiser work out whether there are really better ways of doing the job.

My main project uses four dimensional arrays on a RISC processor
(really RISC, INMOS Transputers to be specific). Explicitly using
pointers ALMOST TRIPLES the execution speed of the code.

Do not take this silly advice about pointers if you are extensively using
multidimensional arrays and you care about execution time.

(nor if you are interested in large data bases, either. I've seen code
in FORTRAN try to build a tree heirarchy. blecchhh.)

If your project is small enough that not using pointers is appropriate,
and you are hiring programmers who are uncomfortable with it, your
project should probably be written in Pascal.

mt

Newsgroups: comp.lang.c