X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Thu, 11 Aug 2011 09:42:27 +0200 From: Corinna Vinschen To: cygwin AT cygwin DOT com Subject: Re: regex_t internals: can we use re_magic to tell whether a regex has been regcomp'd? Message-ID: <20110811074227.GA16868@calimero.vinschen.de> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Aug 10 19:07, Fischer, Matthew L wrote: > We are porting code from Linux that is attempting to determine whether > a regular expression has been properly regcomp'd and not freed. The > code from Linux is looking into the buffer inside regex_t. On Which is kind of scary, IMHO. Using the internals of the regex_t structure other than the ones blessed by the POSIX standard is a sure way to write non-portable code. See http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/regex.h.html The only officially documented member of regex_t is re_nsub. So, why does the code check the internals at all? Why is it important that something has been allocated or not? Shouldn't the application code be happy to rely solely on the return value of regcomp? > Cygwin, the "buffer" (not the same field name) is hidden inside > re_guts which has a comment that dissuades us from using it for this > purpose. Rightfully. Please note that the regex code is *not* Cygwin-specific. This code is actually FreeBSD code, with only minor changes to port it to Cygwin, plus an extension to allow the GNU \< and \> expressions. > However, from looking at the Cygwin implementation, it looks > like if re_magic is != 0 then the regexp is valid and has been > regcomp'd and not regfree'd. Is this interpretation correct? Well, I never actually examined the guts of regcomp/regfree more than necessary, but it seems you're right. No guarantees, though. IMHO, if the application code has to check the internals of the regex_t structure to know if it called regfree on it, it's a bug in the application. Rather than doing that, it should keep track of its regcomp/regfree calls by using an external state variable. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple