mkdir() won't do it for me

[Bill Reid]

Have you used *all* current and future* implementations then? No,
thought not.

BWHAHAHAHAHAHAHAHAHA!!! Have I "used all future
implementations"!!!! BRILLIANT!!!!

This is why you should never "argue" with a troll...insane troll logic
is impossible for a "normal" to even comprehend, let alone "disprove"...

I might use CreateDirectory or whatever other non-standard function is
provided.

The OP's system uses mkdir()! More brilliance! Somebody asks
about mkdir(), therefore "I would use CreateDirectory"!!!

I have not said not to use it just that it is not topical here. If you
don't like the focus of this group, tough.

Nope, that's not all you said. But the take-away message here
is "don't ever post any C code that includes any functions not included
in the C standard, but we're a little fuzzy on which C standard because
frankly nobody really uses the most recent C standards, but in any event
<deeeeep breath>, if it doesn't appear in ANY ANSI C standard it is
'off-topic', and don't try to sneak any IEEE POSIX stuff by us, neither,
or we'll be on you like stink on a skunk <deeeeeeeeeep breath>".

But seriously, what's the REAL problem here? I mean, I couldn't
help but notice posting C code in a group called "comp.lang.c" seemed
to get some panties in a bunch...any thoughts as to why? I've got
mine...

No, I mean professionals who want to provide something that will work
and do it in a predictable timescale.

You mean like "Rod Pemberton"? Or his revered colleague the guy
with the potato chip database?

You obviously don't know how to write C properly.

Of course not, because you just said so. I'm sure "Rod Pemberton"
would agree, and the potato chip database guy, and the guy who
threatened to shoot people with a bow and arrow if they ask where
his code is...

I'll tell you what, I'm ready to learn...I'm gonna buy a big bag of
"Lay's" and start cataloging each delicious chip tomorrow, in preparation
for my new career in "professional programming"...

If you did you would
know that 90% of most projects can be written in strict C90.

Did you know that 93.4568% of all statistics are just made up?

Also, remember those <deeeeeeeep breaths> I included in your
topicality statement for the group? You might want to take one right
now, because you are already past the point where you are making
a complete fool of yourself.

Then, that
90% does not need to be changed when porting.

WAAAAAYYYY past the point...
Maybe you're just another alias for "Rod Pemberton" and this is
all just another one of his "jokes"?

Unless mkdir or some other non-standard code you are using behaves in s
subtly different manner so that normally it will work but in some
situations it will fail.

It always starts with an inability to THINK, doesn't it...remember, we
don't have an ANSI C STANDARD way to create a directory in the first
place.

Now, here's something really hard, but I want you to try: just keep that
FIRST thought in your head (it's your "thought" after all) even if a
SECOND thought also needs to be considered, such as, "we've got some
code that does file manipulation and we want to 'port' it to our
system rather than re-write it all from scratch to save some time".

Once you prove you can handle TWO thoughts, we'll work up to
THREE...but I'M not holding MY breath...

So educate them.

OK, I'm just going to go ahead and conclude from all the evidence
you've presented that you've never worked a day in your life in an
actual place of business (previously, I safely concluded you've never
worked anywhere near a software house that has to deal with portability
of a massive C codebase to a wide variety of systems)...

Show me the reference in the C standard.

IEEE Standard 1003.1, Portable Operating System Interface for
Computer Environments, as tightly "bound" to the C programming
language.

I'll save you the trouble,
there isn't one, so it is not standard C and not topical.

comp.std.c (or whatever) is just around the corner, check it out and
cease your trolling...

You are showing your ignorance again.

I hate it when I do that! I must be because you asserted it, just
like "Rod Pemberton" asserted it takes three months print a magazine!

The printf standard is right there
in the C standard with clearly defined behaviour.

It's right there in Section 8.1, "Referenced C Language Routines" in
IEEE 1003.1 as well. So I guess it is a STANDARD library routine,
just not actually part of the C programming language per se...

The wheel being standardised would have no impact on the development of
the jet engine. C being standardised does not prevent extensions being
provided for things not covered by the C standard, in fact the C
standard specifically allows it.

Here is where you have to try really hard and keep THREE things
in your head at once...isn't "mkdir()" indeed just yet another of those
"extensions" SPECIFICALLY ALLOWED BY THE "C STANDARD"?

If you want to argue that the focus of this group be changed at least
first learn what the focus is

Oh, I'm not going to "argue" what the focus is, I'm just going to
post appropriate code examples written in the C language from
time to time no matter what you or "Rod Pemberton" or any
other similarly mentally-situated person feels about it. Again,
I suggest a little deep-breathing and perhaps the trick of counting
to 10 before you post...also, the basic idea of not saying anything
unless you have something constructive to contribute is good too...

and what is covered by the C standard and
then get your facts right in your post.

I did make mistakes as always...intelligent, thoughtful people learn
and grow (and in my case, re-learn what I already knew!).

For example, the OP specifically stated:

And then later I averred that:

Actually, it is PRECISELY the POSIX "Unix" argument; reading
between the coffee grounds in my salvaged copy of IEEE 1003.1
(and looking at some of my own code!), I see in Section 5.6.1.2
"<sys/stat.h> File Modes":

S_IWUSR Write permission for the file owner class.

So again, I have displayed my profound ignorance...I am deeply
shamed...

Also, I might mention that in addition to not adding that
"permissions" argument to the code I posted using "mkdir()",
the OP might also be stymied by the declaration/definition of:

unsigned dir_num=count_file_path_dirs(file_path);

Since I forgot to include:

unsigned count_file_path_dirs(char *file_path) {
unsigned num_dirs=0;
char *search_ptr=file_path;

while((search_ptr=strchr(search_ptr,'\\'))!=NULL) {
search_ptr++;
num_dirs++;
}

return num_dirs;
}

Of course, the code is bone-stock ANSI C standard, but oddly
assumes there is such a thing on a system as a "directory" but ANSI
C doesn't think directories even exist but even so you can use
ANSI C to manipulate directories <deeeeeeeeep breath> just

You might find these links helpful
http://clc-wiki.net/wiki/C_community:comp.lang.c:Portability_attitude
http://clc-wiki.net/wiki/intro_to_clc

I generally don't click on links provided in Usenet posts as a
security precaution...there's a lot of mentally-unstable weirdos
on Usenet, doncha know ("Rod"?)...

 

[Random832]

BWHAHAHAHAHAHAHAHAHA!!! Have I "used all future implementations"!!!!
BRILLIANT!!!!

This is why you should never "argue" with a troll...insane troll logic
is impossible for a "normal" to even comprehend, let alone
"disprove"...

I don't know - the bit about future implementations does a pretty good
job at disproving it.

 

[Chris Torek]

comp.std.c (or whatever) is just around the corner ...

comp.std.c is for discussions like "shouldn't the third word of
the fourth paragraph on page 47 of draft X be `shall' instead of
`may'?" There is some overlap between "on-topic" items for both
comp.std.c and comp.lang.c, but -- in my opinion anyway -- the
thrust of the two groups is quite different: comp.lang.c is mainly
about using what we have now, while comp.std.c is mainly about
changing what we will have ten years from now.

Also, I might mention that in addition to not adding that
"permissions" argument to the code I posted using "mkdir()" ...

Depending on whether the system is POSIX-like or not. Note that
POSIX discussions really belong in comp.unix.programmer (that
group's name predates POSIX, hence the word "unix" instead of
"posix" ... just as "comp.lang.c" predates the ANSI C standard,
hence the name, which should perhaps have been
"comp.lang.standard-c-and-nothing-else" ).

the OP might also be stymied by the declaration/definition of:

unsigned dir_num=count_file_path_dirs(file_path);

Since I forgot to include:

unsigned count_file_path_dirs(char *file_path) {
unsigned num_dirs=0;
char *search_ptr=file_path;

while((search_ptr=strchr(search_ptr,'\\'))!=NULL) {
search_ptr++;
num_dirs++;
}

return num_dirs;
}

For what it is worth, this again makes the mistake of using backslash
instead of forward slash, so it will not work on actual POSIX
systems. This is easy to fix, but after fixing that, it still
gives a wrong answer for, e.g.:

count_file_path_dirs("this//that/the///other")

(In fact, the whole idea is a little flawed. Compare path names
like "./foo" and "/foo", for instance. Note that while POSIX says
that multiple slashes *within* a pathname are equivalent to a single
slash, it allows multiple *leading* slashes to have special meaning,
so "foo/bar" and "foo//bar" are identical, but "/foo" and "//foo" may
be either identical or different.)

If you want to know what to do on Windows systems (e.g., how to
treat path names like "A:\\foo" vs "\\foo"), one of the many
comp.os.ms-windows.* groups is probably the most appropriate place.
(The double backslashes here are meant in the C sense, to prevent
the letter f from being part of the \f form-feed escape.)

Of course, the code is bone-stock ANSI C standard, but oddly
assumes there is such a thing on a system as a "directory" but ANSI
C doesn't think directories even exist but even so you can use
ANSI C to manipulate directories <deeeeeeeeep breath> just
not create them, read them, delete them, rename them <deeeep breath>...

For instance, you cannot -- at least not without using "#ifdef"s
-- create code that works correctly on both POSIX systems and (e.g.)
vxWorks 5.5 systems, even though both of those support ANSI C89.
(vxWorks 6.x has some POSIX support, with some restrictions. This
means, among other things, that there are two *different* ways to
call mkdir()!)

 

[CBFalconer]

.... snip ...

Nope, that's not all you said. But the take-away message here
is "don't ever post any C code that includes any functions not
included in the C standard, but we're a little fuzzy on which C
standard because frankly nobody really uses the most recent C
standards, but in any event <deeeeep breath>, if it doesn't appear
in ANY ANSI C standard it is 'off-topic', and don't try to sneak
any IEEE POSIX stuff by us, neither, or we'll be on you like stink
on a skunk <deeeeeeeeeep breath>".

Congratulations. Now you are finally beginning to catch on. Of
course, if you include the (std C) source for that function in the
article, it can then be critiqued along with everything else.

 

[Nick Keighley]

Absolutely correct, but I believe that you can use '/' for what the
OP was working on and have it be portable to a very large majority
of all the general-purpose computer systems manufactured after
1990 (unfortunately, probably not the one I'm typing this on without
another "tweak")...

VAX? Trax?

I did follow up and note that my definition of "POSIX-compliant"
isn't so much strict compatibility but rather just "sort of looks like
POSIX"...I don't know how that could possibly cause confusion...


Also I noted the difference in the number of arguments to "mkdir()",
and the specifics of the "permissions" argument...other than that, and
probably a bunch of other stuff, it's totally POSIX-compliant! Who
knew MS-DOS was actually a Unix system!

you are an idiot.

 

[Flash Gordon]

Flash Gordon <[email protected]> wrote in message

This is why you should never "argue" with a troll...insane troll logic
is impossible for a "normal" to even comprehend, let alone "disprove"...


I generally don't click on links provided in Usenet posts as a
security precaution...there's a lot of mentally-unstable weirdos
on Usenet, doncha know ("Rod"?)...

Set up your system properly and you can safely click on any link. Or you
can Google this group for the history of that site.

Also, you seem to be associating me with Rod Pemberton, I'm sure he
would agree that he and I have some significantly different opinions.

It's highly likely I would disagree with a lot of the rest of your post,
but the way you were ranting it did not seem worth the effort of reading.

Oh, by the way, *PLONK*, something I don't think you see trolls say,
since they are here to argue.

 

[Bill Reid]

comp.std.c is for discussions like "shouldn't the third word of
the fourth paragraph on page 47 of draft X be `shall' instead of
`may'?"

Yeah, I know...did you know I knew?

Depending on whether the system is POSIX-like or not.

I think you're more hung up on "slashes" than OJ Simpson, but
anyway...

Note that
POSIX discussions really belong in comp.unix.programmer (that
group's name predates POSIX, hence the word "unix" instead of
"posix" ...

Is there a "POSIX" group (not that I care)?

just as "comp.lang.c" predates the ANSI C standard,
hence the name, which should perhaps have been
"comp.lang.standard-c-and-nothing-else" ).

THE NEWSGROUP FOUNDERS COULDN'T PREDICT
"FUTURE IMPLEMENTATIONS"!!!

For what it is worth, this again makes the mistake of using backslash
instead of forward slash, so it will not work on actual POSIX
systems.

Easy, Orenthal...

This is easy to fix, but after fixing that, it still
gives a wrong answer for, e.g.:

count_file_path_dirs("this//that/the///other")

James, please!!! That nonsense is pure, unadulterated POSIX
fol-de-rol! It takes a committee to come up with an abomination
like that!

(In fact, the whole idea is a little flawed. Compare path names
like "./foo" and "/foo", for instance. Note that while POSIX says
that multiple slashes *within* a pathname are equivalent to a single
slash, it allows multiple *leading* slashes to have special meaning,
so "foo/bar" and "foo//bar" are identical, but "/foo" and "file://foo" may
be either identical or different.)

All 100% POSIX true...I know all this because I just recently read
the POSIX standard, then had to lie down for a week due to bureaucratic
wooziness...

If you want to know what to do on Windows systems (e.g., how to
treat path names like "A:\\foo" vs "\\foo"), one of the many
comp.os.ms-windows.* groups is probably the most appropriate place.

Why, since what I posted works great on Windows systems, just
not on systems with pathnames created by pathological weirdos pushing
the limits of the standard?

(The funniest thing about my copy of the POSIX standard is
Section B.1.2.12 "WeirdNIX...or destructive QA of a standard.",
where they have a contest to come up with the most ridiculous
example of a compliant implementation detail possible...what
did you expect from the creators of the "Obfuscated C Code
Contest"...)

BTW, I think you're in the running with "this//that/the///other"...an
operating system designed by a benevolent dictator like Bill Gates
would never allow that...

For instance, you cannot -- at least not without using "#ifdef"s
-- create code that works correctly on both POSIX systems and (e.g.)
vxWorks 5.5 systems, even though both of those support ANSI C89.
(vxWorks 6.x has some POSIX support, with some restrictions. This
means, among other things, that there are two *different* ways to
call mkdir()!)

Well, at least that means full employment for programmers!

 

[Bill Reid]

I don't know - the bit about future implementations does a pretty good
job at disproving it.

Yup, anybody without a time machine is gonna be SOL...and I so
wanna visit Buck Rogers in the 25th century...

I like your new name, not that I know what the old one was...try to
live up to it with a lot of jumbled up spelling, syntax, and logic, and
you'll fit right in to the "new Usenet"!

 

[Bill Reid]

Congratulations. Now you are finally beginning to catch on.

Yeah, took me a while, even longer to "comply" unfortunately...

Of
course, if you include the (std C) source for that function in the
article, it can then be critiqued along with everything else.

Oh hell, it might be in assembler for all I know...why do I think that
if I called it "black_function_that_creates_directory_from_pathstring()"
you might "accept" it a little easier, and just "critique" the remaining
ANSI C code...

 

[Bill Reid]

Set up your system properly and you can safely click on any link.

Or you
can Google this group for the history of that site.

Hmmmm..."or" is not the appropriate word here, because it doesn't
matter what the "history" of the site is, if it is a "spoofed" link...

Also, you seem to be associating me with Rod Pemberton, I'm sure he
would agree that he and I have some significantly different opinions.

His arms are too short to box with God...are you just a super-hero,
or something more?

It's highly likely I would disagree with a lot of the rest of your post,
but the way you were ranting it did not seem worth the effort of reading.

Well, we all value rants differently...

Oh, by the way, *PLONK*, something I don't think you see trolls say,
since they are here to argue.

Well, good for you, "Flash"...about five more unemployed insane
ex-programmers to go, and I'll have made this group safe for intelligent
adults...

 

[Bill Reid]

you are an idiot.

You're a genius...your momma told me...