regcomp (regex.h) - is it needed to free memory?

[=?ISO-8859-2?Q?Jaros=B3aw_Rafa?=]

Hello,
I have a question about the regular expression functions from #include
<regex.h>. The regcomp() function compiles a regular expressions and "in
the background" allocates some memory for the compiled RE. You can free
that memory with regfree() if you don't need the RE anymore.
BUT the question is: if I want to change the RE, and re-compile it using
*the same regex_t structure* in regcomp(), do I have to call regfree()
first to free the memory allocated to old compiled RE, or can I just
call regcomp(), and it will free or reallocate the memory by itself (so
that there won't be a memory leak)?

 

[Flash Gordon]

Hello,
I have a question about the regular expression functions from #include
<regex.h>.

<snip>

They are not part of standard C and so not topical here. Since I happen
to know of a regex.h on Unix system it is possible that you are using
Unix and so comp.unix.programmer *might* be an appropriate place to ask.
However, reading their FAQ and checking there archives would be a good
idea so you don't make the same mistake you made in posting here.

 

[Jack Klein]

Hello,
I have a question about the regular expression functions from #include
<regex.h>. The regcomp() function compiles a regular expressions and "in
the background" allocates some memory for the compiled RE. You can free
that memory with regfree() if you don't need the RE anymore.
BUT the question is: if I want to change the RE, and re-compile it using
*the same regex_t structure* in regcomp(), do I have to call regfree()
first to free the memory allocated to old compiled RE, or can I just
call regcomp(), and it will free or reallocate the memory by itself (so
that there won't be a memory leak)?

Third party libraries are off-topic here. You'll need to ask this
question in a group or on a mailing list that supports the library. If
it came with your compiler, you could ask in a compiler specific
support group.

 

[=?ISO-8859-2?Q?Jaros=B3aw_Rafa?=]

Flash Gordon napisa³(a):

They are not part of standard C and so not topical here. Since I happen

I think you are too restrictive about what is on- and off-topic on this
group. Maybe they aren't a part of the language standard - but,
actually, AFAIK *no* system calls are a part of the C language standard!
However, they are a part of the POSIX standard and they should be
present on any OS that is POSIX-compliant. So, in my opinion, they may
quite well be discussed here, as C is tightly tied to POSIX.

 

[Chris Dollin]

Flash Gordon napisał(a):

I think you are too restrictive about what is on- and off-topic on this
group.

Several people disagree.

Maybe they aren't a part of the language standard - but,
actually, AFAIK *no* system calls are a part of the C language standard!

That's true but irrelevant. C has a library, and that /is/ described
by the C standard; what's more, as far as I know the regular-expression
stuff isn't a system call, it's just library code.

However, they are a part of the POSIX standard and they should be
present on any OS that is POSIX-compliant.

Yes, POSIX has its own library functions and system calls.

So, in my opinion, they may quite well be discussed here, as C is
tightly tied to POSIX.

Nope. For POSIX stuff, see a POSIX-aware newsgroup. Why do you think
C is "tightly tied" to POSIX?

 

[santosh]

Flash Gordon napisa³(a):

I think you are too restrictive about what is on- and off-topic on this
group.

Not IMO.

Maybe they aren't a part of the language standard - but,
actually, AFAIK *no* system calls are a part of the C language standard!
Yes.

However, they are a part of the POSIX standard and they should be
present on any OS that is POSIX-compliant.
Wrong.

So, in my opinion, they may
quite well be discussed here, as C is tightly tied to POSIX.

ISO/IEC 9899:1999 is for C as POSIX is for an OS API. This doesn't mean
that a particular POSIX compliant OS API has to be implemented in C,
(though most are).

 

[Random832]

Yes, POSIX has its own library functions and system calls.

POSIX does not have "system calls" [though it does define the meaning of
the string given to a call to system() - presumably not the same thing
as what either of you meant]

 

[Chris Dollin]

Yes, POSIX has its own library functions and system calls.

POSIX does not have "system calls" [though it does define the meaning of
the string given to a call to system() - presumably not the same thing
as what either of you meant]

You're right about the latter. As to the former, that's going to
depend on what one means by a "system call", and here I make no
opinion, merely remarking that the term was introduced by
Jaroslaw's:

| I think you are too restrictive about what is on- and off-topic on this
| group. Maybe they aren't a part of the language standard - but,
| actually, AFAIK no system calls are a part of the C language standard!
| However, they are a part of the POSIX standard and they should be
| present on any OS that is POSIX-compliant. So, in my opinion, they may
| quite well be discussed here, as C is tightly tied to POSIX.

and I sloppily followed that use without checking.

 

[CBFalconer]

Flash Gordon napisa³(a):


I think you are too restrictive about what is on- and off-topic on
this group. Maybe they aren't a part of the language standard - but,
actually, AFAIK *no* system calls are a part of the C language
standard! However, they are a part of the POSIX standard and they
should be present on any OS that is POSIX-compliant. So, in my
opinion, they may quite well be discussed here, as C is tightly tied
to POSIX.

You are wrong. This group deals only with the portable C language,
as described in the ISO C standards. comp.unix.programmer can be
used for Posix questions, as can other system specific newsgroups.

 

[Random832]

POSIX does not have "system calls" [though it does define the meaning of
the string given to a call to system() - presumably not the same thing
as what either of you meant]

You're right about the latter. As to the former, that's going to
depend on what one means by a "system call", and here I make no
opinion, merely remarking that the term was introduced by
Jaroslaw's: [snipped]
and I sloppily followed that use without checking.

Right. There is a certain class of POSIX and XSI library functions that
are traditionally considered "system calls" in that they are implemented
mostly at the kernel level rather than the user level on unix-like
systems, and I'm pretty sure that's what he meant. But POSIX doesn't
actually specify the manner of implementation.

 

[tehn.yit.chin]

You are wrong. This group deals only with the portable C language,
as described in the ISO C standards. comp.unix.programmer can be
used for Posix questions, as can other system specific newsgroups.

That is one grip I have about this group. It is too restrictive in
discussing the C language. I have been a reader of this newsgroup for
many years and have noticed that the SNR is gently decreasing.

Why can't we discuss advancement of C? This appears to be frown upon as
it is outside the scope of the newsgroup because it has not been
describe in the any C standard.

Let's break out of the square and think about the advancement of the
langauge.

 

[santosh]

That is one grip I have about this group. It is too restrictive in
discussing the C language.

For the sake of accuracy. Most other groups on C, here on Usenet,
(except comp.std.c), and on the Web have a much wider scope. Hence,
IMHO, devoting a group or two to just standard C is not unwise. As you
can note, the topicality restrictions don't prevent the group from
being a high volume one.

I have been a reader of this newsgroup for
many years and have noticed that the SNR is gently decreasing.

That would probably be because of the emergence of spamming and Google
groups. Again, IMHO, relaxing the topicality would only cause a further
reduction of SNR.

Why can't we discuss advancement of C? This appears to be frown upon as
it is outside the scope of the newsgroup because it has not been
describe in the any C standard.

Let's break out of the square and think about the advancement of the
langauge.

Indeed. But in comp.std.c instead. Most regulars here are also regulars
there, so you won't be losing out on expert viewpoints.