C struct and pointer

Question

I'm following a book and teaching myself C. Right now I'm trying to use a bitArray to find the # of primes under a specific number. As default, the book gives me a struc and a function starts with:

typedef struct _seg {
   int  bits[256];
   struct _seg *next, *prev;
} seg;

*seg whichseg(int j){

}

However, this function *seg whichseg(int j){ is throwing me an error when i compile. I'm wondering that is it should be seg * with a star after seg? And what exactly does this function mean, is it making j automatically a seg struct?

Thank you all :-)

whichseg is a function whose return type is a structure i.e. seg* — user1502952, Sep 22 '13 at 04:45
It should be `seg *whichseg...`. You should get a different book. Identifiers starting with underscore are reserved for use in libraries. — Gene, Sep 22 '13 at 04:45
@Gene When I did a subject in C language at university they have told me to follow this style: https://wiki.cse.unsw.edu.au/info/CoreCourses/StyleGuide#Structs — Sarp Kaya, Sep 22 '13 at 04:58
@SarpKaya: That's bad advice: "All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces." If you use both a tag and a typedef for a given struct, there's no real need for them to be distinct; `typedef struct foo { ... } foo;` is just fine. — Keith Thompson, Sep 22 '13 at 08:08

score 1 · Answer 1 · edited Sep 22 '13 at 06:47

1

You should put * after seg i.e. seg*

As of now your function is doing nothing and by making above changes, compiler will still complain saying that value is not ruturned.

I am assuming you want to put j value in your node and I am putting it is bits array at zero location.

seg* whichseg(int j){
       seg* segNode = malloc(sizeof(seg));
       seg->bits[0]=j;
       return seg;
}

edited Sep 22 '13 at 06:47

Jens Gustedt

76,821
6
102
177

answered Sep 22 '13 at 04:41

Vallabh Patade

4,960
6
31
40

So what's the different if I make it int whichseg ? what exactly does this seg* do? thanks! – jackhao Sep 22 '13 at 04:44
1

Function is returning a pointer of type seg. You should create a pointer of seg and allocate memory to it and return the pointer. – Vallabh Patade Sep 22 '13 at 04:47
What you want to do with this function?? – Vallabh Patade Sep 22 '13 at 04:49
@VallabhPatade thanks so much for your help. I'm trying to locate the position of the bit corresponding to j. I also have 2 functions called int whichint(int j) and whichbit(int j). – jackhao Sep 22 '13 at 04:50
Not clear what you are trying to do. I told you how to use your function, you use it and go ahead. – Vallabh Patade Sep 22 '13 at 04:52
malloc() returns a void * type pointer, you should use (seg *)malloc(sizeof(seg)) instead. – TwoCode Sep 22 '13 at 04:56
Don't cast the return of `malloc` http://stackoverflow.com/questions/605845/do-i-cast-the-result-of-malloc – Jens Gustedt Sep 22 '13 at 06:46

TwoCode · Answer 2 · 2013-09-22T04:57:03.310

0

seg* whichseg(int j){

}

This means the function returns a pointer to struct _seg.

edited Sep 22 '13 at 04:57

answered Sep 22 '13 at 04:49

TwoCode

127
7

score -3 · Answer 3 · answered Sep 22 '13 at 05:28

-3

Thank-you for this question. Have modified your code, just a bit, as:

typedef struct _seg {
   int          bits[256];
   struct _seg *prev;
   struct _seg *next;
} seg;

seg * whichseg(int j)
{
   seg *this;

   this = malloc(sizeof(seg));

   this->prev = this->next = NULL;

   this->bit = //your computation here

   // the code that called whichseg must free the seg
   // structured that was malloc'd in whichseg!!
   return this;

}

First, of all it is ok to use underscores. Their usage in this compilation unit won't cause (or shouldn't) cause a problem. Usually "_names" are private variables or methods, but it really just depends on your shop standard.

whichseg is just a function that returns a pointer to a seg structure that is allocated on the heap. Your code is responsible for any memory that is allocated but not freed while the program runs. When your program completes all leaks should get repaired(at least in Windows?).

Hope this helps.

answered Sep 22 '13 at 05:28

JackCColeman

3,777
1
15
21

2

-1, your topic about names with underscore is just wrong. These names **are** reserved and any system might use e.g `struct _seg` for internal use. Using such names makes code non-portable and may cause headaches much later when you try to use your code on a different machine. Just don't do it, and in particular don't teach beginners the habit of doing it. – Jens Gustedt Sep 22 '13 at 06:51
2

You're mistaken about the underscores. N1570 7.1.3: "All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces." It's not too likely that a particular tag name will actually collide with something used by the implementation, but there's no point in risking it. The tag and the typedef name don't have to be distinct: `typedef struct seg { ... } seg;` is fine. – Keith Thompson Sep 22 '13 at 08:10
@KeithThompson, it depends on how well you understand what "file scope" means! Your legal document does **NOT** say do not do this. Rather, what it says is that within a "file scope" the names are reserved. Finally, if "_x" doesn't work then try "__x"!! – JackCColeman Sep 22 '13 at 21:54
I understand perfectly well what "file scope" means. Your declaration of `struct _seg` is at file scope. A conforming implementation may define its own `struct _seg`; if it does, your code will fail to compile. Dropping the underscore fixes that problem. I fail to understand your apparent obsession with rejecting what the C standard says (it's not "my" legal document, it's what defines the C programming language). And of course `__x` is no better. – Keith Thompson Sep 22 '13 at 22:12
@KeithThompson, if my code fails to compile, then I will have to change the var. name. OH NO!! – JackCColeman Sep 23 '13 at 01:30
What if your code fails to compile 5 years from now, when it needs to be ported to a new implementation? What if you just write confirming code in the first place? There are times when there are legitimate reasons for writing non-portable code. This is not one of them. What advantage does your sloppiness give you? – Keith Thompson Sep 23 '13 at 02:05
And I'm curious: what exactly did you mean by "*it depends on how well you understand what "file scope" means*"? – Keith Thompson Sep 23 '13 at 03:22
@KeithThompson, when you use a library, how often do you compile its source code along with your own (i.e. within the same compilation unit)? **Not** often. Hence, _ names are **not** often a problem. – JackCColeman Sep 24 '13 at 05:22
@JackCColeman: The headers are compiled along with the application. You can avoid the problem simply by dropping the underscore. I didn't say they're *often* a problem, but they're a potential problem, and one that's *trivially* avoided. And you haven't answered my question. – Keith Thompson Sep 24 '13 at 05:57
@KeithThompson, somewhere in the above comments, I mentioned that underscores are usually used for private variables. I you write C code that exposes a variable and name it "_something" then you're asking for trouble. Thus, "file scope" is a rather vague term and be construed to mean several things (just to answer your question). – JackCColeman Sep 26 '13 at 06:01
There is nothing vague or ambiguous about "file scope"; it's rigorously defined. Your `_seg` is a struct tag defined at file scope. Try defining a `struct _IO_FILE` in a program with `#include ` on a system that uses GNU libc and see what happens. Then explain why `struct _seg` is any better. – Keith Thompson Sep 26 '13 at 14:37
@KeithThompson, sorry, I don't use GNU. – JackCColeman Sep 26 '13 at 20:07
@JackCColeman: Then replace `struct _IO_FILE` by whatever `FILE` is defined as on the system you use. The point still stands. – Keith Thompson Sep 26 '13 at 20:13
@KeithThompson, to the extent that I have always wanted to pick a "_" name that has a 100% probability of causing a problem, then you have a point. – JackCColeman Sep 27 '13 at 21:32
@JackCColeman: You seem unwilling to acknowledge anything I say. Bye. – Keith Thompson Sep 27 '13 at 21:53

C struct and pointer

3 Answers3