[Bug 68647] New: apr_pstrdup() with string literal

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=68647

            Bug ID: 68647
           Summary: apr_pstrdup() with string literal
           Product: Apache httpd-2
           Version: 2.5-HEAD
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: All
          Assignee: bugs@httpd.apache.org
          Reporter: marc.stern@approach-cyber.com
  Target Milestone: ---

At many place, all over the code, we see apr_pstrdup() used with string
literals.
Is this needed? This question is useful for 2 points:
1. Could we optimize the code and remove that call?
2. More important: in a new code, is there sometimes a requirement to not use a
string literal? This would allow to avoid mistakes.
Obviously, the cases where we explicitely modify the string don't fall into
this question.

Example: in mod_include.c, we have that code:
   token->value = apr_pstrdup(ctx->dpool, "");
Why?

At many places, apr_pstrdup() is used for values used in apr_table_setn(). Is
there a specific requirement in this case?

Thanks for clarifying this

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 68647] apr_pstrdup() with string literal

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=68647

--- Comment #2 from Marc Stern <ma...@approach-cyber.com> ---
From Stefan Fritsch's answer in the mailing list (thanks for the pointer), I
deduce I get safely use string literals directly (when I'm sure the string is
not modified obviously).
Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 68647] apr_pstrdup() with string literal

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=68647

Joe Orton <jo...@redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from Joe Orton <jo...@redhat.com> ---
This is a great thing to discuss on dev@ rather than in a bug :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 68647] apr_pstrdup() with string literal

[bu...@apache.org]

https://bz.apache.org/bugzilla/show_bug.cgi?id=68647

--- Comment #1 from Christophe JAILLET <ch...@wanadoo.fr> ---
Hi,

see the same question a few years ago:
   https://lists.apache.org/thread/hr2t965lgdcb0f8vzpq2b8jh771z3m6h



For apr_pstrdup() vs apr_table_setn(), I see 2 possibilities:

1) it can be a question of lifetime of the string.

Most of memory allocations in httpd are done using pools which can have a
different lifetimes.
So sometimes it is needed to copy a string in another pool because it is needed
in another context with another lifetime.


2) When apr_table_setn() is used, the string is not copied in the table, only a
reference to it is stored in the table. So, if you need to modify the string,
then you need to copy it first. Otherwise, the original string is modified
as-well.


Anyway, it is likely that some optimisation can be done.
Patches welcomed :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org