$form_state['values'] not reflecting an accurate decimal value (i.e. non-significant zeros are dropped)

New summary: Editing a decimal field, with allowed values of varying decimal lengths, to round # value breaks when you try to edit the node again.
---
With the following configuration: Drupal 6.13, CCK 6.x-2.4. Field type is decimal, precision 10, scale 1.

What follows should flesh out this issue with more detailed testing. Of course, let me know if this is user error...

To reproduce:

1) Create a decimal field with the following allowed values.

32
44.1
48
88.2
96
176.4
192

(Considering the OP's similar case, I guess that any list with varying lengths after the decimal point would do this.)

2) Edit a node containing this decimal field, setting a value for this field to one of the round values, ie a value WITHOUT a ".1", ".2" such as "32" or "48". Hit Save. See that it shows fine in the node details.

3) Return to edit the node, and see if the the pop-up menu for that field is now "blank." Your previously entered value will be erased if you just hit "save" now.

In other words, editing this field to a round # only sticks until you try to edit the node again.

4) Try steps 2-3 again, but this time enter one of the values WITH something after the decimal, ie "44.1", "88.2" etc. That works and doesn't break!

5) Now, change the field's allowed values to the following, and the problem goes away:
32.0
44.1
48.0
88.2
96.0
176.4
192.0

By padding all the round numbers with a ".0" the problem stops. This workaround points to the cause of this issue.

When decimal fields are read from database during node load, the values of these fields are stored in the node object as strings and contains all non-significant zeroes (1). That's the format of the values that needs to be used in the allowed values list.

(1) This is not a CCK issue, but something that depends on the Database API in Drupal, and that is caused by how the PHP drivers to perform SELECT statements return results to the application layer.

marked #400184: Decimal value not preselecting on editing a node as a duplicate of this issue

if it is known that DB layer will preserve non-significant zeros (because of the nature of the decimal type),
why should number_decimal_validate get rid of those zeros?
there are cases when they where provided and whipped by the validator
and where they are not provided they aren't filled into $form_sate

currently it read:

      $value = str_replace($element['#decimal'], '.', $value);
      $value = round($value, $element['#scale']);
      form_set_value($element[$field_key], $value, $form_state);

but this might be solved by making it read:

      $value = str_replace($element['#decimal'], '.', $value);
      $value = round($value, $element['#scale']);
      
      list($units, $fraction) = explode('.', $value);
      if (is_null($fraction)) {
        $fraction = '';
      }
      $fraction = str_pad($fraction, $element['#scale'], '0');
      $value = $units . '.' . $fraction;
      
      form_set_value($element[$field_key], $value, $form_state);

which will preserve the usual string nature of the values in $from_state['values']
(since they use to come from submission they use to be string instead of double)

this becomes an issue for comparing the user submission value against the #default_value (#739962: CCK decimal: non-significant zeros conflict),
and might be tolerable if user doesn't provide non-significant zeros, but being provided in the form and dropped on validation doesn't make much sense

moreover, it seems that a user submitted value wouldn't be of type double, since it is expected to come from a form

not sure if this would require to support empty string as well
just in case, this is the same patch but in addition supporting empty strings